Re: [OSM-talk-fr] Liens Wikidata (Était : ERDF (et RFF) ont changé de nom)

[osm . sanspourriel]

Parce que dans ce cas tu as une associatedStreet qui porte le wikidata=Q...

Les tronçons font partie de la rue en question.

Jean-Yvon


Le 15/06/2016 à 13:14, Jo - winfi...@gmail.com a écrit :
2016-06-11 18:17 GMT+02:00 Christian Quest >:


Il faut par contre bien faire attention à l'objet sur lequel ces
tags sont mis (comme les tags wikipedia d'ailleurs).

Un tag wikidata=* ne devrait logiquement exister qu'une seule fois
dans la base OSM.


Pourquoi? Disons que j'ai une entrée Wikidata pour une rue spécifique. 
En OSM cette rue sera probablement sectionnée et même si elle ne l'est 
pas initiellement, elle pourra toujour être coupé par après. Le même 
va pour des bâtiments ou des oeuvres d'art composé de plusieurs 
parties. Si je fais une requête overpass, je veux télécharger toutes 
les pièces composantes en spécifiant wikidata=Q...


Polyglot



___
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] Liens Wikidata (Était : ERDF (et RFF) ont changé de nom)

[Jo]

2016-06-11 18:17 GMT+02:00 Christian Quest :

> Il faut par contre bien faire attention à l'objet sur lequel ces tags sont
> mis (comme les tags wikipedia d'ailleurs).
>
> Un tag wikidata=* ne devrait logiquement exister qu'une seule fois dans la
> base OSM.
>

Pourquoi? Disons que j'ai une entrée Wikidata pour une rue spécifique. En
OSM cette rue sera probablement sectionnée et même si elle ne l'est pas
initiellement, elle pourra toujour être coupé par après. Le même va pour
des bâtiments ou des oeuvres d'art composé de plusieurs parties. Si je fais
une requête overpass, je veux télécharger toutes les pièces composantes en
spécifiant wikidata=Q...

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

Re: [OSM-talk-fr] Liens Wikidata (Était : ERDF (et RFF) ont changé de nom)

[Christian Quest]

Il faut par contre bien faire attention à l'objet sur lequel ces tags 
sont mis (comme les tags wikipedia d'ailleurs).


Un tag wikidata=* ne devrait logiquement exister qu'une seule fois dans 
la base OSM.


Pas contre, des tags liant une propriété de l'objet (par exemple son 
nom, son opérateur, etc) peuvent exister autant de fois que nécessaire.



Le 10/06/2016 à 12:22, Christian Rogel a écrit :


Le 9 juin 2016 à 09:27, François Lacombe > a écrit :


Tenez, ça va dans le bon sens : iD vient juste d'être mis a jour avec 
cette fonctionnalité intéressante


https://twitter.com/bhousel/status/740567649894031369?s=09

François



Sur la liste anglophone, l’annonce de l’ajout automatique d’une 
référence Wikidata mérite un peu plus d’explications :
la dernière version d’iD crée automatiquement le binôme clé- valeur 
wikidata = Qnn si le « name » est trouvé comme titre d’un article 
du Wikipedia.


La discussion s’est focalisée sur les noms de lieu administratifs, 
mais, cela inclut bien d’autres choses comme les monuments, gares et 
autres équipements.


Frederick Ramm s’est demandé, si ce n’était pas un « mechanical 
edit », mais, Simon Poole a répondu que cela n’est pas un import massif.


L’auteur de l’implémentation, Minh Nguyen a précisé qu’il y a, en ce 
moment, 1 778 365 références Wikidata pour des « human settlements » 
et au dessus, dans la hiérarchie, 2 225 880

« administrative terrtorial entitiy ».

L’avantage de llier un objet géographique à Wikidata est de fournir un 
ancrage plus stable (labilité des OSM ID).


Bryan Housel, mainteneur de iD a dit espérer que cette fonctionnaité 
serait ajoutée aux autres éditeurs OSM. Si cela arrive, c’est une 
évolution très importante d’OSM.



Christian R.


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



--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] Liens Wikidata (Était : ERDF (et RFF) ont changé de nom)

[Christian Rogel]

> Le 9 juin 2016 à 09:27, François Lacombe  a écrit :
> 
> Tenez, ça va dans le bon sens : iD vient juste d'être mis a jour avec cette 
> fonctionnalité intéressante
> 
> https://twitter.com/bhousel/status/740567649894031369?s=09 
> 
> François
> 

Sur la liste anglophone, l’annonce de l’ajout automatique d’une référence 
Wikidata mérite un peu plus d’explications :
la dernière version d’iD crée automatiquement le binôme clé- valeur wikidata = 
Qnn si le « name » est trouvé comme titre d’un article du Wikipedia.

La discussion s’est focalisée sur les noms de lieu administratifs, mais, cela 
inclut bien d’autres choses comme les monuments, gares et autres équipements.

Frederick Ramm s’est demandé, si ce n’était pas un « mechanical edit », mais, 
Simon Poole a répondu que cela n’est pas un import massif.

L’auteur de l’implémentation, Minh Nguyen a précisé qu’il y a, en ce moment, 1 
778 365 références Wikidata pour des « human settlements » et au dessus, dans 
la hiérarchie, 2 225 880
« administrative terrtorial entitiy ».

L’avantage de llier un objet géographique à Wikidata est de fournir un ancrage 
plus stable (labilité des OSM ID).

Bryan Housel, mainteneur de iD a dit espérer que cette fonctionnaité serait 
ajoutée aux autres éditeurs OSM. Si cela arrive, c’est une évolution très 
importante d’OSM.


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

Re: [OSM-talk-fr] Liens Wikidata (Était : ERDF (et RFF) ont changé de nom)

[François Lacombe]

Tenez, ça va dans le bon sens : iD vient juste d'être mis a jour avec cette
fonctionnalité intéressante

https://twitter.com/bhousel/status/740567649894031369?s=09

François
Le 8 juin 2016 12:08 PM, "François Lacombe"  a
écrit :

> Bonjour Jean-Yvon,
>
> Le 8 juin 2016 à 03:03,  a écrit :
>
>>
>>
>>
>>
>> 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*.
>>
>
> Je pensais urbanisme, Wikidata proposant nativement la gestion des noms
> multiples et les rattachant à une notion commune (voire à plusieurs).
> Ce n'est pas parce qu'OSM est plus riche en noms que cette solution est
> adaptée. Vu l'embrouille avec les name:*, name_x, etc... wikidata challenge
> tout ça efficacement.
>
>
>> Mais tous *les short_name, old_name, alt_name n'ont pas d'équivalent
>> dans Wikidata* ou je dis une connerie ?
>>
>
> Les attributs dans wikidata sont figés par les admins, mais à géométrie
> variable tout de même (on peut demander à en créer).
> Il suffit d'en discuter avec eux.
>
>
>> 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
>>
> Comment le sais-tu ? Regarder sur streetview ne suffit pas.
> Le poste porte le nom d'une entreprise, c'est un client avec de fortes
> demande de puissance vu son activité. Le poste a de fortes chances d'être
> un poste de livraison privé en limite de propriété.
>
>
>> Car ce n'est pas un poste privé mais un poste pour cette boîte et
>> quelques maisons.
>>
> Comment en être si sûr ?
> Pour les postes privés (qui portent le plus souvent le nom du client), le
> distributeur ne peut pas raccorder de tiers dessus.
> Ce n'est pas parce que le poste prend l'apparence d'une cabine en bordure
> de domaine public qu'il y a forcément des maisons raccordées dessus.
>
>
>
>> Donc on devrait avoir un ref:ERDF:GDO (si ce ne me trompe) qui ne serait
>> pas MLTVULCA.
>>
> De tels codes ont un format bien particulier comme expliqué sur le wiki,
> MLTVULCA reste le nom d'usage du poste et jamais sa référence.
>
>
>> 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.
>>
>
> C'est le nom d'usage, donc on le met dans name=*.
>
>
>> Le wiki power=substation
>>  dit :
>> name   Le nom d'usage
>> du poste électrique recommandé
>> operator   Nom
>> de l'exploitant du poste électrique optionnel
>> ref   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.
>>
> Ok pour ça.
>
>
>> 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.
>>
> Il n'y a pas de vérité dans le domaine, ce qui compte c'est ce qui est
> indiqué sur le terrain. Et en l'occurence il y a des majuscules.
> J'ai aussi tendance à remettre les noms en minuscules, mais ca se situe
> entre l'erreur manifeste et la vérité :)
>
> Dans le cas ou on voudrait conserver la vue terrain, ceci est valide :
> name=Viking
> ref=10829
> ref:ERDF:gdo=76540P10829
>
>
> Il va falloir revenir sur ce tag ref:ERDF:gdo parce que :
> il contient ERDF qui n'existe plus
> il ne contient pas FR alors qu'il ne concerne que la France et rien
> d'autre.
>
> ERDF c'est aussi un fond Européen qui peut financer des projets ayant une
> réalité sur terrain, avec des référence... risque de collision.
> On devrait profiter pour rendre ce tag plus conforme pendant qu'il n'y a
> que 1000 objets et que le wiki est relativement complet.
>
>
>>
>> C'est par contre dit assez clairement sur 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 

Re: [OSM-talk-fr] Liens Wikidata (Était : ERDF (et RFF) ont changé de nom)

[François Lacombe]

Bonjour Jean-Yvon,

Le 8 juin 2016 à 03:03,  a écrit :

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

Je pensais urbanisme, Wikidata proposant nativement la gestion des noms
multiples et les rattachant à une notion commune (voire à plusieurs).
Ce n'est pas parce qu'OSM est plus riche en noms que cette solution est
adaptée. Vu l'embrouille avec les name:*, name_x, etc... wikidata challenge
tout ça efficacement.


> Mais tous *les short_name, old_name, alt_name n'ont pas d'équivalent dans
> Wikidata* ou je dis une connerie ?
>

Les attributs dans wikidata sont figés par les admins, mais à géométrie
variable tout de même (on peut demander à en créer).
Il suffit d'en discuter avec eux.


> 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
>
Comment le sais-tu ? Regarder sur streetview ne suffit pas.
Le poste porte le nom d'une entreprise, c'est un client avec de fortes
demande de puissance vu son activité. Le poste a de fortes chances d'être
un poste de livraison privé en limite de propriété.


> Car ce n'est pas un poste privé mais un poste pour cette boîte et quelques
> maisons.
>
Comment en être si sûr ?
Pour les postes privés (qui portent le plus souvent le nom du client), le
distributeur ne peut pas raccorder de tiers dessus.
Ce n'est pas parce que le poste prend l'apparence d'une cabine en bordure
de domaine public qu'il y a forcément des maisons raccordées dessus.



> Donc on devrait avoir un ref:ERDF:GDO (si ce ne me trompe) qui ne serait
> pas MLTVULCA.
>
De tels codes ont un format bien particulier comme expliqué sur le wiki,
MLTVULCA reste le nom d'usage du poste et jamais sa référence.


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

C'est le nom d'usage, donc on le met dans name=*.


> Le wiki power=substation
>  dit :
> name   Le nom d'usage
> du poste électrique recommandé
> operator   Nom
> de l'exploitant du poste électrique optionnel
> ref   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.
>
Ok pour ça.


> 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.
>
Il n'y a pas de vérité dans le domaine, ce qui compte c'est ce qui est
indiqué sur le terrain. Et en l'occurence il y a des majuscules.
J'ai aussi tendance à remettre les noms en minuscules, mais ca se situe
entre l'erreur manifeste et la vérité :)

Dans le cas ou on voudrait conserver la vue terrain, ceci est valide :
name=Viking
ref=10829
ref:ERDF:gdo=76540P10829


Il va falloir revenir sur ce tag ref:ERDF:gdo parce que :
il contient ERDF qui n'existe plus
il ne contient pas FR alors qu'il ne concerne que la France et rien d'autre.

ERDF c'est aussi un fond Européen qui peut financer des projets ayant une
réalité sur terrain, avec des référence... risque de collision.
On devrait profiter pour rendre ce tag plus conforme pendant qu'il n'y a
que 1000 objets et que le wiki est relativement complet.


>
> C'est par contre dit assez clairement sur 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
>  *il faut
> aller sur une page non référencée dessus !*
>
Parce que ca ne concerne qu'une partie du parc.
C'est par contre indiqué sur
http://wiki.openstreetmap.org/wiki/WikiProject_Power_networks/France que je
suis entrain de remettre à jour.



> *Donc : doit-on mettre le nom *TOUT EN MAJUSCULE et éliminer le test pour
> les 

Re: [OSM-talk-fr] Liens Wikidata (Était : ERDF (et RFF) ont changé de nom)

[osm . sanspourriel]

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 

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: (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 Qxx?)


*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=...)

 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 

Re: [OSM-talk-fr] Liens Wikidata (Était : ERDF (et RFF) ont changé de nom)

[Jérôme Seigneuret]

L'idée est bonne à voir si la mise en place et l'usage peut être fait
facilement en prenant en compte ce que j'ai mis en avant comme
problématique. Le tout étant de pouvoir faire une mise à jour simple et
partout.

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"

Le 7 juin 2016 à 16:51, Nicolas Dumoulin  a écrit :

> Le Tue, 7 Jun 2016 16:04:26 +0200,
> Jérôme Seigneuret  a écrit :
> > J'utilise pas encore ce système de WIKIDATA mais je trouve pas ça très
> > simple pour un "contributeur humain" d'où le fait d'utiliser une
> > version et des robots de maintenance qui le feront bien meiux que moi
> > et qui pourront aussi le faire pour les softs de saisi avec un mode
> > d'alerte en cas d'utilisation d'une saisie manuelle d'éléments
> > obsolètes.
>
> Je suis d'accord que ce n'est pas adapté pour un contributeur humain
> (en tout cas, pas de manière évidente). Mais je parle justement des
> outils et scripts qui font du traitement automatique des données OSM.
> Je parle donc des robots et pas des contributeurs. Je trouve que ça
> pourrait être intéressant que ces robots s'appuient sur des codes faits
> pour les robots en utilisant une base (comme les fichiers "projects" de
> taginfo) pour traduire ces codes en langage orienté contributeur.
> Mais bon, c'est juste une idée :-)
>
> --
> Nicolas Dumoulin
>
>
> ___
> 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] Liens Wikidata (Était : ERDF (et RFF) ont changé de nom)

[Nicolas Dumoulin]

Le Tue, 7 Jun 2016 16:04:26 +0200,
Jérôme Seigneuret  a écrit :
> J'utilise pas encore ce système de WIKIDATA mais je trouve pas ça très
> simple pour un "contributeur humain" d'où le fait d'utiliser une
> version et des robots de maintenance qui le feront bien meiux que moi
> et qui pourront aussi le faire pour les softs de saisi avec un mode
> d'alerte en cas d'utilisation d'une saisie manuelle d'éléments
> obsolètes.

Je suis d'accord que ce n'est pas adapté pour un contributeur humain
(en tout cas, pas de manière évidente). Mais je parle justement des
outils et scripts qui font du traitement automatique des données OSM.
Je parle donc des robots et pas des contributeurs. Je trouve que ça
pourrait être intéressant que ces robots s'appuient sur des codes faits
pour les robots en utilisant une base (comme les fichiers "projects" de
taginfo) pour traduire ces codes en langage orienté contributeur.
Mais bon, c'est juste une idée :-)

-- 
Nicolas Dumoulin


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

Re: [OSM-talk-fr] Liens Wikidata (Était : ERDF (et RFF) ont changé de nom)

[Jérôme Seigneuret]

Et donc paf :
http://taginfo.openstreetmap.org/keys/traffic_calming#projects
Donc en clair, tous les projets qui utilise des clés doivent faire une
déclaration pour savoir si ces projets seront impactés.

Wikidata déporte la problématique de maintenance des clés.

En clair ça veux dire que les outils de saisi doivent faire appel à ce
système pour définir les correspondances (outil intermédiaire) permettant à
l'utilisateur de continuer à saisir des clés et à en faire une restitution
en base sur des clés wikidata

Et grâce à cette intermédiaire, pouvoir restituer un système de clé=valeur
fournissant la dernière version valide de toutes clés ou couples de
clé=valeur répondant à la dernière version.

Ou alors tu utilise ce système pour faire des upgrade dans toutes les
applications et dans la base pour mettre à jour les clés ou couple de
clés/valeurs d'une version du schéma à l'autre.
Il faut dans ce cas avoir un versionnement du système de clé.

J'utilise pas encore ce système de WIKIDATA mais je trouve pas ça très
simple pour un "contributeur humain" d'où le fait d'utiliser une version et
des robots de maintenance qui le feront bien meiux que moi et qui pourront
aussi le faire pour les softs de saisi avec un mode d'alerte en cas
d'utilisation d'une saisie manuelle d'éléments obsolètes.

C'est un peu le principe d'alerte en développement JAVA quand tu exploites
une fonction déprécié (ou autre langage) dans une librairie.


Le 7 juin 2016 à 14:30, Nicolas Dumoulin  a écrit :

> Salut,
>
> Je reviens sur cette idée de wikidata avec une découvert que je viens
> de faire par hasard, en cherchant une icône de ralentisseurs.
> La découverte, ce sont les "projects" dans taginfo qui permet entre
> autres de lier un élément de taginfo à wikidata.
> Et donc paf :
> http://taginfo.openstreetmap.org/keys/traffic_calming#projects
> Là, on a le lien entre les attributs "traffic_calming=*" et l'élément
> wikidata Q1198538
> Comment ça marche, c'est par ici :
> http://wiki.openstreetmap.org/wiki/Taginfo/Projects
> Et un fichier de description des correspondances ici :
> http://tools.wmflabs.org/wp-world/wikidata/tags.php
> Où on trouve par exemple la correspondance
> "amenity=bar" avec https://www.wikidata.org/wiki/Q187456
> Ça ouvre la perspective avec cet exemple d'utiliser cette base
> d'association pour extraire les bars non plus avec l'attribut
> "amenity=bar", mais avec le code wikidata Q187456. Ainsi, si la
> communauté française fait pression (hoho) pour renommer "amenity=bar"
> en "amenity=troquet", les applications ne seront pas impactées,
> puisqu'il suffira de mettre à jour de fichier "Projects" pour cette
> association d'entités.
> Bon, mon exemple est un peu foireux, et l'idée reste prospective, mais
> je trouve cela très enthousiasmant :-)
>
> Bonne journée
>
> --
> Nicolas Dumoulin
>
>
> ___
> 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] Liens Wikidata (Était : ERDF (et RFF) ont changé de nom)

[Nicolas Dumoulin]

Salut,

Je reviens sur cette idée de wikidata avec une découvert que je viens
de faire par hasard, en cherchant une icône de ralentisseurs.
La découverte, ce sont les "projects" dans taginfo qui permet entre
autres de lier un élément de taginfo à wikidata.
Et donc paf :
http://taginfo.openstreetmap.org/keys/traffic_calming#projects
Là, on a le lien entre les attributs "traffic_calming=*" et l'élément
wikidata Q1198538
Comment ça marche, c'est par ici :
http://wiki.openstreetmap.org/wiki/Taginfo/Projects
Et un fichier de description des correspondances ici :
http://tools.wmflabs.org/wp-world/wikidata/tags.php
Où on trouve par exemple la correspondance 
"amenity=bar" avec https://www.wikidata.org/wiki/Q187456
Ça ouvre la perspective avec cet exemple d'utiliser cette base
d'association pour extraire les bars non plus avec l'attribut
"amenity=bar", mais avec le code wikidata Q187456. Ainsi, si la
communauté française fait pression (hoho) pour renommer "amenity=bar"
en "amenity=troquet", les applications ne seront pas impactées,
puisqu'il suffira de mettre à jour de fichier "Projects" pour cette
association d'entités.
Bon, mon exemple est un peu foireux, et l'idée reste prospective, mais
je trouve cela très enthousiasmant :-)

Bonne journée

-- 
Nicolas Dumoulin


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