Wikidata talk:WikiProject Weather observations

Consentement

La requête type via (c:Commons:OTRS) ne semble pas s'appliquer lorsque l'ayant droit est un organisme comme un gouvernement. Un gouvernement ne peut signer un courriel débutant par Je confirme par la présente être l'auteur et le titulaire unique et exclusif de l'œuvre. Il faudra probablement contacter Wikimedia et s'assurer d'avoir une couverture globale pour les données gouvernementales.

En effet. J'ai commencé à discuter avec d'autres pour voir quelle forme ça pourrait prendre.
Idéalement, si l'organisme pouvait préciser directement sur sa page web que les données X, Y sont dans le domaine public, ça éliminerait le problème. Là, quand je regarde, par exemple, https://meteo.gc.ca/canada_f.html, rien n'est précisé. On a bien un lien vers « gouvernement ouvert », mais on ne sait pas à quoi ça s'applique précisément, ni même qu'est-ce qui s'applique précisément. Simon Villeneuve (talk) 00:19, 20 October 2017 (UTC)

La mention directe sur le site web me semble la solution la plus simple. Je garde ça en tête. Dirac (talk) 08:21, 21 October 2017 (UTC)

Identifiant de la station

Le nom utilisé pour la ville de New York ne pourra pas être généralisé: Data:NOM DE L'ORGANISME/NOM DE LA STATION MÉTÉOROLOGIQUE.tab

Il y a en effet risque de collision. Pour les stations canadiennes, il y a 469 doublons sur les 8742 stations identifiées.

Sous GNU/Linux, faire la commande suivante pour identifier les doublons sur le fichier des stations:

awk -F , '{print $1}' Station\ Inventory\ EN.csv | uniq -d | sed 's/"//g' 

Ok. J'ai mis ça comme idée préliminaire, mais faut revoir. Idéalement, je crois qu'utiliser un identifiant international unique serait l'idéal (je crois que c'est le cas de WIGOS). En effet, ça permettrait d'éviter à devoir préciser l'organisme et on pourrait écrire les noms sous la forme « Data:Weather observations/IDENTIFIANT ». Autrement, si on utilise un identifiant local propre à un organisme particulier, je crois qu'il faudra garder la forme « Data:NOM DE L'ORGANISME/IDENTIFIANT LOCAL ».
Le désavantage est que ça rend difficile l'identification rapide d'une station particulière. On pourrait faire une page générale sous la forme « Data:Weather observations/List of meteorological stations » liant l'identifiant à la station et préciser dans l'intro du fichier le nom de la station. À peaufiner. Simon Villeneuve (talk) 00:19, 20 October 2017 (UTC)

Le mot magique : redirection ! Créer les pages avec les identifiants uniques (Data:Weather observations/IDENTIFIANT), classés dans les catégories appropriées, puis créer les redirections avec les noms des stations météo (Data:NOM DE L'ORGANISME/IDENTIFIANT LOCAL), elles aussi dans les catégories appropriées. Aucune collision avec les identifiants uniques et des titres aussi long que souhaités dans les redirections. Tout ça, c'est à la portée d'un bot si on lui fournit un tableau de correspondance. Cantons-de-l'Est (talk) 15:41, 22 October 2017 (UTC)

Oui, les redirections pourraient le faire. Cependant, d'après ce que je lis ici, il semblerait que la catégorisation de ces pages ne soit pas (encore ?) possible. D'ailleurs, il faudrait voir ce que Yurik entend pas « Of course this is only possible if foundation continues to support this effort. » --Simon Villeneuve (talk) 00:26, 23 October 2017 (UTC)

TC ID

Pour les données canadiennes, il y a un identifiant des stations nommé "TC ID. Or, ce code ne correspond ni au code IATA ni au code OACI.

Encore une fois, dans le glossaire d'Environnement Canada il est écrit:

Identifiant (ID) de TC

L'identifiant (ID) de Transports Canada est l'identificateur attribué par Transports Canada pour identifier les rapports météorologiques provenant des stations localisées aux aéroports et sont transmis en temps réel dans des formats d'aviation.

Quelques recherches m'indiquent que ça ne correspond ni à l'un, ni à l'autre. Par exemple, le code pour Isachsen est "WIC" qui n'est pas dans la liste OACI ou IATA:

• https://fr.wikipedia.org/wiki/Liste_des_codes_AITA_des_a%C3%A9roports/W#WI
• https://fr.wikipedia.org/wiki/Liste_des_codes_OACI_des_a%C3%A9roports/W#WI

On verra en temps et lieu s'il est pertinent de demander la création d'une propriété « identifiant de Transports Canada ». Simon Villeneuve (talk) 00:19, 20 October 2017 (UTC)

Si quelqu'un peut créer cette propriété, autant le faire tout de suite parce que ça permettra de commencer à tester des trucs si quelqu'un forge des modèles en Lua. Au pire, il suffira de demander la destruction de la propriété. Cantons-de-l'Est (talk) 15:44, 22 October 2017 (UTC)

Ok, j'ajoute la demande de création de cette propriété au plan de match. --Simon Villeneuve (talk) 00:26, 23 October 2017 (UTC)

Données bidons

Bonjour,

S'il faut créer des modèles et des modules, il faut des données à traiter. Je propose de commencer par créer un fichier qui comprend un ensemble de données bidons. On pourra ainsi produire un démo à montrer aux gens d'Environnement Canada, ainsi qu'aux communautés wikipédienne, wikidatienne et commoniste. Il est en effet rare que des données numériques produisent un engouement (si je puis dire).

Cantons-de-l'Est (talk) 15:52, 22 October 2017 (UTC)

Comme indiqué sur la page, le démo existe déjà pour New York (le climat mensuel). On pourrait créer d'autres modèles/modules Lua pour extraire d'autres données et faire d'autres démonstrations, mais c'est un peu l’œuf ou la poule. En effet, d'après Pasleim, c'est la grande quantité de données importées qui risque de créer un engouement pour le développement de modèles. D'après mes discussions avec Dirac, je crois que c'est déjà gagné pour EC (à moins que la conversion des fichiers en .tab demande des efforts trop grands, mais ce n'est pas mon impression).

Simon Villeneuve (talk) 00:27, 23 October 2017 (UTC)

Le parsing des données est le bout facile. On peut se garder ça pour la fin, ça va juste être du fun. Cela dit, je vais en effet avoir besoin d'une démo pour EC. La maîtrise des concepts à l'interne pour Wikidata est à faire, et on doit aussi tester les possibilités pour voir dans à quel(s) mandat(s) d'EC cela pourra répondre. Cela dit, utiliser les données pour New York serait probablement suffisant dans un premier temps. Voici à quoi j'ai pensé pour débuter:

1. Faire une requête SPARQL où l'on peut utiliser les données d'observations. Par exemple, une recherche d'une ville américaine où la température maximale pour 2016-06 est supérieure à 30°C
2. Faire une liste des stations dans:
   1. une province
   2. un carré lat/lon donné
   3. un point lat/lon + rayon
   4. une localité
3. Téléchargement en vrac des données
4. autre?

Dirac (talk) 12:26, 23 October 2017 (UTC)

@Cantons-de-l'Est, Simon Villeneuve, Dirac: je comprends la démarche mais pourquoi ne pas partir sur un extrait des données réelles ? (dans l'idéal un extrait sur un lieu limité mais avec tout les champs possibles pour modéliser la structuration dans Wikidata).

Sinon, on peut créer quelques modèles à peu de frais pour commencer (notamment pour faire des graphes, pas besoin de Lua pour cela ce me semble, cf. infra). Inversement, je n'ai aucune ide de la façon de ré-exploiter les données tabulées de Commons (sans doute avec du Lua mais cela dépasse mes connaissances). Cdlt, VIGNERON (talk) 14:42, 25 October 2017 (UTC)

VIGNERON, Nous ne pouvons pas exploiter directement des données soumises au copyright. Alors que pour les ouvrages écrits, les lois sont plutôt uniformes en ce qui concerne le droit de courte citation, elles sont hétérogènes en ce qui concerne le copyright sur les bases de données. Quant à la proposition de « quelques modèles à peu de frais », c'est un effort inutile parce que lorsque nous aurons les vraies données, ça devra fonctionner immédiatement sans heurt avec une masse de données, sinon le projet est voué à l'échec à cause de la pluie de critiques et de mauvaise réputation qui en résultera. Seul Lua nous donne la flexibilité pour produire les graphiques à la volée. Quant aux modules Lua, nous devons nous inspirer de ce qui a été fait pour New York. Cantons-de-l'Est (talk) 15:44, 25 October 2017 (UTC)

@Cantons-de-l'Est: euh les données ne vont-elles pas justement être libérés en CC0 ? (est-ce que ce n'est pas le point central de toutes cette page ?). Et je parle d'un extrait donc on se trouve clairement dans le droit de courte citation ce me semble (surtout si les données vont être libérées).

Ok pas de modèle de test pour le moment. Sinon as-tu un exemple de « ce qui a été fait pour New York » ? (je ne connais que mw:Template:Graph:Weather monthly history mais qui n'utilise pas Lua et qui n'utilise pas Wikidata non plus, le second point me semblant être largement le plus limitant)

Cdlt, VIGNERON (talk) 16:09, 25 October 2017 (UTC)

VIGNERON, Je croyais à tort que les données de New York étaient « traduites » grâce à Lua. Cantons-de-l'Est (talk) 11:18, 27 October 2017 (UTC)

@Cantons-de-l'Est, Simon Villeneuve, VIGNERON:. J'avais pensé créer l'entrée sur Wikidata pour la station d'observation de Bagotville dans un premier temps, en liant les informations disponibles dans le répertoire des stations d'ECCC aux différentes propriétés sur Wikidata. Cela permettra de faire les liens données brutes -> Wikidata qu'il nous faudra coder dans un script par la suite.

Dans un deuxième temps, j'ai penser relier à cet item les données d'observations mensuelles de Bagotville. Comme ces données ne sont pas encore sous CC0, j'ai pensé les modifier afin d'en créer des factices (ex: en retirant 1°C des mesures de températures), afin d'éviter les problèmes de copyright, le temps de faire nos tests (sous Commons et/ou Wikidata). Voyez-vous un problème à procéder de la sorte pour un échantillon de données?

Dirac (talk) 11:10, 28 October 2017 (UTC)

Non, pas de problème.

QuickStatements

Si tu veux tester l'automatisation de la création, tu peux copier-coller le code suivant dans QuickStatement (faut que tu autorises préalablement WiDaR). Si tu veux, je peux le faire. --Simon Villeneuve (talk) 11:40, 28 October 2017 (UTC)

CREATE
LAST    Lfr     "Bagotville A"
LAST    Len     "Bagotville A"
LAST    Dfr     "station météorologique de Bagotville"
LAST    Den     "Bagotville meteorological station"
LAST    P31     Q190107
LAST    P625    +48.33, -71.00
LAST    P2044   +159.1
LAST    P17     Q16
LAST    P150    Q176
LAST    P150    Q615914
LAST    P150    Q2879166
LAST    P150    Q2875784
LAST    P4136   int.wmo.wigos-0-20000-0-71727
LAST    P4150   "Data:Environnement Canada/Bagotville.tab"

J'ai tenté l'importation dans WiDaR, ça m'a donnée les erreurs suivantes:

ERROR: LAST Lfr "Bagotville A" is not a Wikidata item (Qxxx). Did you forget to set a wiki to convert from articles to items?
ERROR: LAST Len "Bagotville A" is not a Wikidata item (Qxxx). Did you forget to set a wiki to convert from articles to items?
ERROR: LAST Dfr "station météorologique de Bagotville" is not a Wikidata item (Qxxx). Did you forget to set a wiki to convert from articles to items?
ERROR: LAST Den "Bagotville meteorological station" is not a Wikidata item (Qxxx). Did you forget to set a wiki to convert from articles to items?
ERROR: LAST P31 Q190107 is not a Wikidata item (Qxxx). Did you forget to set a wiki to convert from articles to items?
ERROR: LAST P625 +48.33, -71.00 is not a Wikidata item (Qxxx). Did you forget to set a wiki to convert from articles to items?
ERROR: LAST P2044 +159.1 is not a Wikidata item (Qxxx). Did you forget to set a wiki to convert from articles to items?
ERROR: LAST P17 Q16 is not a Wikidata item (Qxxx). Did you forget to set a wiki to convert from articles to items?
ERROR: LAST P150 Q176 is not a Wikidata item (Qxxx). Did you forget to set a wiki to convert from articles to items?
ERROR: LAST P150 Q615914 is not a Wikidata item (Qxxx). Did you forget to set a wiki to convert from articles to items?
ERROR: LAST P150 Q2879166 is not a Wikidata item (Qxxx). Did you forget to set a wiki to convert from articles to items?
ERROR: LAST P150 Q2875784 is not a Wikidata item (Qxxx). Did you forget to set a wiki to convert from articles to items?
ERROR: LAST P4136 int.wmo.wigos-0-20000-0-71727 is not a Wikidata item (Qxxx). Did you forget to set a wiki to convert from articles to items?
ERROR: LAST P4150 "Data:Environnement Canada/Bagotville.tab" is not a Wikidata item (Qxxx). Did you forget to set a wiki to convert from articles to items?

Dirac (talk) 07:09, 29 October 2017 (UTC)

J'ai finalement entré les données à la main. Voir Bagotville A, station météorologique. Dirac (talk) 08:26, 29 October 2017 (UTC)

Il fallait copier-coller les commandes à partir du code. J'ai fait un autre test avec Esquimalt Harbour et ça marche :

CREATE
LAST	Lfr	"Esquimalt Harbour"
LAST	Len	"Esquimalt Harbour"
LAST	Dfr	"station météorologique canadienne"
LAST	Den	"canadian meteorological station"
LAST	P31	Q190107
LAST	P625	@48.43/123.44
LAST	P2044	3U11573
LAST	P17	Q16
LAST	P131	Q1974
LAST	P131	Q5399239
LAST	P127	Q348789
LAST	P4136	"int.wmo.wigos-0-20000-0-71798"
LAST	P4150	"Data:Environnement Canada/Esquimalt Harbour.tab"

@Cantons-de-l'Est, Simon Villeneuve, VIGNERON: Je vais écrire un script qui transforme les méta-données des stations afin de les mettre sur Wikidata. La première difficulté que je rencontre est de différencier les dates de début et de fin pour les 3 types d'observations disponibles:

1. Horaire
2. Quotidienne
3. Mensuelle

J'ai regardé pour utiliser applies to part (P518) et je comprends que si je créé un élément pour chaque type d'observations, je vais pouvoir les utiliser pour qualifier les dates de début et de fin. Est-ce que mon raisonnement est bon? Dirac (talk) 18:20, 5 September 2018 (UTC)

@Dirac:Hum, pas sûr de comprendre ce que tu veux dire. J'ai l'impression que tu mélanges les éléments Q et les propriétés P.
Ce que j'ai dit au début de cette section, c'est qu'il est facile de créer les éléments pour les ~8,000 stations météo canadiennes et d'y renseigner plusieurs propriétés pour chacun d'eux (pays, localisation administrative, coordonnées géographiques, code WMO, code de transport Canada, etc.).
L'insertion des données des stations météo est plus problématique. Je ne sais pas où en est rendu la discussion, mais de ce que je m'en souviens, on ne savait pas si on allait les mettre sur Wikidata ou sur Commons. Si c'est sur Commons, il y a le précédent « New York » qui montre la marche à suivre. Si c'est sur Wikidata, il y a, d'après ma compréhension actuelle de la chose, une panoplie de nouvelles propriété à créer avant de procéder. Ainsi, par exemple et pour aller dans le même sens que ton intervention, si on crée une propriété du genre « condition météorologique », tu pourras renseigner cette dernière avec un chiffre et une unité, puis utiliser le qualificatif point in time (P585) pour préciser le moment où ce renseignement est vrai. Simon Villeneuve (talk) 19:47, 5 September 2018 (UTC)

@Simon Villeneuve: Dans un premier temps, je vais mettre les informations sur les stations dans Wikidata (sans les observations). Voici par exemple les informations disponibles dans le fichier d'EC pour la station de Bagotville:

Station ID: 5889
Name:BAGOTVILLE A
Last Year:2018
Province:QUEBEC
First Year:1942
HLY First Year:1953
HLY Last Year:2018
DLY First Year:1942
DLY Last Year:2018
MLY First Year:1942
MLY Last Year:2017
Latitude (Decimal Degrees):48.33
Longitude (Decimal Degrees):-71
Latitude:482000000
Longitude:-710000000
Climate ID:7060400
TC ID:YBG
Station ID:5889
Elevation (m):159.1
WMO ID:71727

Comme tu vois, il y a en fait 4 dates pour la station. L'année d'inauguration de la station, et les années de début/fin pour les observations horaires/quotidiennes/mensuelles (notées HLY/DLY/MLY). Je cherche comment faire pour intégrer ces dates dans l'information de la station. As-tu une proposition? Dirac (talk) 21:00, 5 September 2018 (UTC)

@Dirac: Salut !
D'abord, j'ai deux problèmes avec le TC ID que tu donnes. Le premier est que ce code semble plutôt être celui de IATA airport code (P238) et non de Transport Canada LID (P5699). Ensuite, la contrainte de ce code est qu'il ne doit y en avoir qu'un seul par élément, alors que celui-ci est déjà utilisé par Bagotville Airport (Q2875784).
Ensuite, concernant tes 4 dates, la première peut être simplement rentrée avec inception (P571) ou service entry (P729). Pour les autres dates, je pense que cela sera lié (à la/aux) nouvelle(s) propriété(s) qui (sera/seront) créé(s). Simon Villeneuve (talk) 17:52, 6 September 2018 (UTC)

@Simon Villeneuve:

1- Selon le glossaire du site web sur les données climatiques d'ECCC, L'identifiant (ID) de Transports Canada est l'identificateur attribué par Transports Canada pour identifier les rapports météorologiques provenant des stations localisées aux aéroports et sont transmis en temps réel dans des formats d'aviation. C'est clairement pas le IATA airport code (P238). Qu'est-ce qui te fait affirmer que ce n'est pas Transport Canada LID (P5699)?

2- Je pense que service entry (P729) est la plus approprié de tes deux suggestions pour l'année de la première observation.

3- Pour les dates les propriétés à créer, as-tu une proposition? Genre "Observation météorologique horaire/quotidienne/mensuelle" ? Dirac (talk) 19:04, 6 September 2018 (UTC)

@Dirac:

1- Ben, tout simplement Q2875784#P238. De ce que j'ai vu de mes quelques centaines d'ajouts sur le sujet, Transport Canada LID (P5699) possède généralement 4 caractères (exemple).

2- Ok

3- Je sais pas. C'est une étape à laquelle on a encore le temps de réfléchir. Simon Villeneuve (talk) 19:18, 6 September 2018 (UTC)

@Simon Villeneuve: 1- Dans ce cas ou pourra demander une nouvelle propriété ou encore la mettre de côté.

3- Je vais me mettre à l'écriture du script qui va créer le QuickStatements pour toutes les stations. Je n'ai pas d'échéancier, mais ça ne devrait pas être trop trop long. Tu proposes qu'on y réfléchisse d'ici à ce que le script soit au point?

4- Je cherche une équivalence à service entry (P729) mais qui pour la fermeture. Que penses-tu de date of official closure (P3999) ?

Dirac (talk) 19:28, 6 September 2018 (UTC)

@Dirac:

1- On a de la difficulté à se comprendre. Ce que je te dis, c'est qu'il y a soit une erreur concernant l'identifiant de Transport Canada pour la station de Bagotville A, soit que TC a décidé de faire correspondre son identifiant à celui du IATA airport code (P238) dans certains cas. D'ailleurs, si tu regardes une page comme en:List of airports in Canada (A–B), tu peux voir les différences entre les différents codes et voir que plusieurs aéroports, dont Bagotville, ne semblent pas avoir d'identifiant TC (ou avoir un identifiant TC qui est le même que P238). Bref, je pense que tu as un peu de recherche à faire à ce niveau pour éclaircir la chose.

3- Personnellement, je ne suis pas à l'aise avec l'importation de toutes les données d'observation sur Wikidata pour les raisons que j'ai déjà exposées. @VIGNERON:, lui, semble l'être. Je vous laisserais donc traiter ce point.
Cela n'empêche pas de faire d'abord un script pour créer les éléments pour les stations et leur caractéristiques.
4- Oui, ça me semble être la bonne chose à faire. De toute manière, si nous trouvons éventuellement une meilleure propriété pour la chose, il est facile de transférer l'information via petscan. Simon Villeneuve (talk) 12:16, 7 September 2018 (UTC)

@Simon Villeneuve:

1- L'information à propos de TC ID vient directement du fichier d'EC. C'est leur appélation, leur numéro et leur définition dans leur glossaire. Je ne fais aucune interprétation ici. Comme on a de la difficulté à se comprendre à ce propos, je vais le laisser de côté dans un premier temps, et on y reviendra au besoin.

3- Ce n'est pas dans mon plan pour le moment d'importer les données d'observations dans Wikidata, pour des raisons de licences. À court terme, il semble peut vraisemblable qu'EC libère les données sous CC-0. Je vais donc les importer sur Commons, puisque la licence du gouverment ouvert -Canada est compatible avec Commons. Cela dit, j'ai quand même besoin d'inscrire le type d'observation dans la fiche de la station sur Wikidata. Je fais la demande pour une propriété pour chacune des types d'observations ? Dirac (talk) 13:23, 7 September 2018 (UTC)

Implantation

@Simon Villeneuve, VIGNERON: J'ai terminé une version fonctionnelle du script transformant le fichier CSV du Service météorologique du Canada (SMC) en code QuickStatement. J'en ai fait un logiciel libre que j'ai rendu disponible sur framagit.

Avant de me lancer dans la création des quelques 8700 stations, j'aimerais que vous puissiez jeter un oeil sur le résultat.

Voici les données pour la station « ACADIA FOREST EXP ST » rendues disponibles par le SMC:

Name:ACADIA FOREST EXP ST
Province:NEW BRUNSWICK
Climate ID:8100100
Station ID:6106
WMO ID:
TC ID:
Latitude (Decimal Degrees):45.99
Longitude (Decimal Degrees):-66.36
Latitude:455925000
Longitude:-662148000
Elevation (m):54
First Year:1955
Last Year:2010
HLY First Year:
HLY Last Year:
DLY First Year:1955
DLY Last Year:2010
MLY First Year:1955
MLY Last Year:2006

Une fois mon script utilisé pour le créer, ça donne en QS:

#### ACADIA FOREST EXP ST ####
CREATE
LAST	Lfr	"ACADIA FOREST EXP ST"
LAST	Dfr	"station météorologique du Service météorologique du Canada pour ACADIA FOREST EXP ST, Nouveau- Brunswick, Canada"
LAST	Len	"ACADIA FOREST EXP ST"
LAST	Den	"Meteorogical Service of Canada's station for ACADIA FOREST EXP ST, New Brunswick, Canada"
LAST	P31	Q190107
LAST	P625	@45.99/-66.36
LAST	P2044	54U11573
LAST	P17	Q16
LAST	P131	Q1965
LAST	P127	Q349450
LAST	P729	+1955-01-01T00:00:00Z/09
LAST	P3999	+2010-01-01T00:00:00Z/09
LAST	P6242	"8100100"
LAST	P6339	Q59657036	P580	+1955-01-01T00:00:00Z/09	P582	+2010-01-01T00:00:00Z/09
LAST	P6339	Q59657037	P580	+1955-01-01T00:00:00Z/09	P582	+2006-01-01T00:00:00Z/09

Vous trouverez le résultat sur WD dans Acadia Forest Exp St (Q60620470).

Quelques notes:

• Il y a un bogue dans l'engin de QS pour la création de la propriété instance of (P31) avec des références. Je dois repasser par la suite mais je peux le faire à l'aide du script. Vous pourrez d'ailleurs constater que les références sont présentes (URL, langue et date de consultation) pour Acadia Forest Exp St (Q60620470).
• J'ai intégré toutes les informations rendues disponibles par le SMC sur WD, sauf celui du TC ID, tel que discuté plus haut.
• J'ai fait la demande pour deux propriétés, qui ont été approuvées, afin de pouvoir tout case l'information. Il s'agit de Meteorological Service of Canada climate site ID (P6242) et reports periodicity (P6339).

Avez-vous des commentaires ou des suggestions d'amélioration?

Merci,

Dirac (talk) 19:22, 15 January 2019 (UTC)

Salut,
Ça me semble bien !
La seule chose que je note est l'utilisation de majuscules dans les étiquettes et les descriptions. D'expérience, je rencontre rarement des expressions en majuscules dans ces deux champs. En fait, je rencontre rarement l'utilisation de majuscules tout court sur Wikidata.
Concernant ton problème de référence pour P31, est-ce seulement cette propriété qui pose problème ? Si oui, tu pourrais simplement mettre ces références sur une ou plusieurs autres propriétés de l'élément (par exemple, sur la valeur de P6242). Je crois remarquer que plusieurs contributeurs se contentent de référencer une seule propriété par élément. Cela a l'avantage de diminuer le temps de référencement des éléments tout en permettant à une personne désirant retracer l'origine de l'info de le faire (ce qu'elle ne pourrait pas faire s'il y avait aucune référence). Simon Villeneuve (talk) 20:16, 15 January 2019 (UTC)

Je pensais que j'étais obligé de conserver le nom des stations en lettres majuscules, mais suite à ton commentaire j'ai réfléchi et ça va être possible de changer ça. Je vais soumettre une mise à jour sous peu.
J'ai effectivement seulement ce problème avec instance of (P31). Je vais voir si le but est toujours présent si je l'attribue à Meteorological Service of Canada climate site ID (P6242). Je te reviens avec une mise à jour. Merci! Dirac (talk) 18:28, 16 January 2019 (UTC)

@Simon Villeneuve: J'ai arrangé les noms. Ça donne par exemple Acadia Forest Exp St (Q60620470). Pour les références, la bonne nouvelle c'est que ça fonctionne mieux sur 6242. La mauvaise nouvelle, c'est que je n'y arrive toujours pas de la manière idéale si je désire mettre les deux références. Si j'y vais avec une seule référence, ça marche (voir l'identifiant de Alma (Q60664309) comme exemple). J'y vais avec une seule référence, celle en anglais, sur 6242 ? Dirac (talk) 17:48, 17 January 2019 (UTC)

Faudrait voir tes lignes de code. Mais même là, je suis pas sûr de pouvoir t'aider.
Sinon, c'est facile de repasser après coup pour sourcer l'ensemble des éléments créés (en P31 ou ailleurs). Simon Villeneuve (talk) 14:04, 18 January 2019 (UTC)

@Simon Villeneuve:, voici une autre proposition. Code QS:

#### Arthurette Birch Ridge ####
CREATE
LAST	Lfr	"Arthurette Birch Ridge"
LAST	Dfr	"station météorologique du Service météorologique du Canada pour Arthurette Birch Ridge, Nouveau-Brunswick, Canada"
LAST	Len	"Arthurette Birch Ridge"
LAST	Den	"Meteorogical Service of Canada's station for Arthurette Birch Ridge, New Brunswick, Canada"
LAST	P31	Q190107
LAST	P625	@46.75/-67.47
LAST	P2044	214.9U11573
LAST	P17	Q16
LAST	P131	Q1965
LAST	P127	Q349450
LAST	P729	+1967-01-01T00:00:00Z/09
LAST	P3999	+1983-01-01T00:00:00Z/09
LAST	P6242	"8100350"	S854	"ftp://client_climate@ftp.tor.ec.gc.ca/Pub/Get_More_Data_Plus_de_donnees/Station%20Inventory%20EN.csv"	S407	Q1860	S813	+2019-01-10T00:00:00Z/11
LAST	P6339	Q59657036	P580	+1967-01-01T00:00:00Z/09	P582	+1983-01-01T00:00:00Z/09
LAST	P6339	Q59657037	P580	+1967-01-01T00:00:00Z/09	P582	+1983-01-01T00:00:00Z/09

Tu peux voir le résultat dans Arthurette Birch Ridge (Q60766161). Ça te semble satisfaisant? Dirac (talk) 19:08, 21 January 2019 (UTC)

Ça me semble bien.
Pour ajouter une référence supplémentaire, ça ne fonctionne pas si tu ajoutes la ligne suivante ?
LAST P6242 "8100350" S854 "URL DE REF EN FRANÇAIS" S407 Q1860 S813 +2019-01-10T00:00:00Z/11
Simon Villeneuve (talk) 20:47, 21 January 2019 (UTC)

Malheureusement non. Voir Ashton Hill (Q60774779) pour le résultat d'une telle requête. Dirac (talk) 20:56, 21 January 2019 (UTC)

J'ai ajouté toutes les quelques 220 stations du Nouveau-Brunswick pour me faire la main. J'ai rencontré quelques pépins (collision dans nom/description, j'ai mis l'identifiant du SMC dans la description pour éviter cela) et l'altitude manquante pour une poignée d'anciennes stations. J'ai fait une 2e passe par la suite pour ajouter la référence vers l'URL en français pour Meteorological Service of Canada climate site ID (P6242). Voir la requête pour les stations météo:

#Stations météo
SELECT ?item ?itemLabel ?coordonn_es_g_ographiques WHERE {
  ?item (wdt:P31/wdt:P279*) wd:Q190107.
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
  OPTIONAL { ?item wdt:P625 ?coordonn_es_g_ographiques. }
}

Try it!

Sélectionner la visualisation sous forme de carte dans le menu à gauche) et faire un zoom sur le NB. @Simon Villeneuve:, si tu ne trouves rien à redire, je continuerais avec le reste du Canada. Dirac (talk) 19:14, 23 January 2019 (UTC)

Ajouts des données sur Bagotville A (Q42393053)

@Cantons-de-l'Est, Simon Villeneuve, Dirac:

Puisque l'on a maintenant l'élément Bagotville A (Q42393053), je propose d'y ajouter les données. En regardant commons:Data:Environnement Canada/Bagotville.tab, il me semble que l'on a déjà quasiment tout ce qu'il faut pour importer les données, par exemple pour la première ligne, voici ma suggestion de structuration des données :

• ⟨ Bagotville A (Q42393053)    ⟩ temperature (P2076) ⟨ 20 ⟩
  point in time (P585) ⟨ 1876-01 ⟩
  applies to part (P518) ⟨ maximum (Q21067467)    ⟩

• ⟨ Bagotville A (Q42393053)    ⟩ precipitation height (P3036) ⟨ 23.9 mm ⟩
  point in time (P585) ⟨ 1876-01 ⟩
  applies to part (P518) ⟨ rain (Q7925)    ⟩

• ⟨ Bagotville A (Q42393053)    ⟩ precipitation height (P3036) ⟨ 0 mm ⟩
  point in time (P585) ⟨ 1876-01 ⟩
  applies to part (P518) ⟨ snow (Q7561)    ⟩

Parmi ce que j'ai repéré comme manquant, il faudrait des propriétés pour jour de précipitation et avoir des éléments plus spécifiques en valeur de applies to part (P518) (par exemple, un élément température maximale plutôt que maximum (Q21067467) (qui est l'élément le plus proche que j'ai trouvé). Et peut-être que determination method (P459) est plus pertinent que applies to part (P518).

Qu'en pensez-vous ?

PS: c'est normal d'avoir point in time (P585) = 1942 alors qu'il y a des données antérieurs à 1942 ? (j'imagine que cela ne s'applique qu'à la automatic weather station (Q846837), mais il y a une petite incohérence qu'il faudrait vérifier).

Cdlt, VIGNERON (talk) 12:12, 1 November 2017 (UTC)

Le fichier Commons lié à cette station est un copié-collé du fichier New York. Je l'ai créé au début du projet pour faire un test.
Sinon, merci pour les exemples. Je réalise qu'il existe certaines propriétés météo dont j'ignorais l'existence. Simon Villeneuve (talk) 16:22, 1 November 2017 (UTC)

J'ai retiré les données avant 1942-09, date de la première observation mensuelle pour Bagotville.

Je propose également de renomment le fichier « Bagotville.tab » pour « Bagotville A (7060400)) monthly observations.tab ». Ça va permettre de distinguer ces données avec d'éventuelles données quotidiennes ou horaires. Des objections? Dirac (talk) 20:47, 1 November 2017 (UTC)

Je connais mal les possibilités de ces fichiers. J'ai une réflexion en 2 étapes :
1- J'ai l'impression qu'il serait possible de mettre tout dans le même fichier. Il s'agirait d'ajouter des lignes "1942-09-01", "1942-09-02", "1942-09-03", etc. en-dessous de "1942-09" et de faire de même pour tous les mois de toutes les années.
2- Si l'option 1 n'est pas possible et qu'il faut séparer les données mensuelles des hebdomadaires et quotidiennes, alors j'opterais pour des noms du genre "Weather conditions/month/FICHIER.tab", "Weather conditions/week/FICHIER.tab" et "Weather conditions/day/FICHIER.tab". Comme ça, on réunirait tous les types de données dans un même "domaine" de sous-pages.
Dans tous les cas, puisqu'il a géré le fichier New York, je crois qu'une discussion avec Yurik à ce sujet serait pertinente. --Simon Villeneuve (talk) 01:14, 2 November 2017 (UTC)

L'option 1 est faisable, mais n'est pas souhaitable. Les observations mensuelles/quoditiennes/horaires n'ont pas les mêmes mesures et ne suivent pas les mêmes règles (pour mesurer le vent notamment). De plus, les personnes qui ont besoins d'observations ont rarement besoin des 3 niveaux en même temps. Il serait donc plus avantageux de séparer les type de données, de cette manière on pourra avoir un type de tableau pour chaque type, plutôt qu'un général avec plein d'élément vide. Il sera aussi possible de télécharger ou traiter uniquement les données d'un seul type à la fois, plutôt que de filtrer à même le script.

Concernant la proposition pour l'option 2, je crois que l'utilisation d'un sous-domaine est la bonne approche. La question que ça soulève est met-on le type de données (Weather conditions/month/FICHIER.tab) ou le nom de la station au premier niveau (Weather conditions/STATION/month/STATION.tab) ? Quand j'ai codé le script Get Canadian Weather, j'ai choisi la deuxième option, car pour les données horaires il y a un fichier par mois par station. Pour Bagotville, ça donne par exemple 780 fichiers pour les données horaires depuis 1942 (et il faut en ajouter un par mois). Si on pense qu'il y a plus de 8k stations, ça va donner un répertoire "/Weather conditions/day/" où il y aurait des centaines de milliers de fichiers. Si on vise plutôt le nom de station pour le premier niveau, ça va être plus tranquille. Pour continuer avec notre exemple, les données mensuelles de Bagotville irait sous "/Weather conditions/Bagotville A (71727)/monthly/Bagotville A (71727).tab"

Ça se tient? Dirac (talk) 13:09, 2 November 2017 (UTC)

Je pense que oui. Je me range à ton idée. Cependant, je pense encore qu'une discussion avec Yurik serait probablement enrichissante. --Simon Villeneuve (talk) 23:51, 2 November 2017 (UTC)

Je lui ai posé les questions. Dirac (talk) 01:05, 4 November 2017 (UTC)

Identification unique des stations

EC a 8742 stations dont 469 qui ont le même nom (~5%). Les stations qui ont le même nom ne peuvent être confondues: les stations ont changé d'endroit ou encore d'instrumentation. Elles ont connu suffisamment de changements pour qu'elles ne puissent être considérées comme étant identique. C'est pourquoi elles ont des entrées différentes et que le nom de la station ne peut donc servir d'identifiant unique.

Plusieurs de ces stations n'ont pas d'identification WIGOS, ce qui fait qu'on ne peut utiliser cette propriété pour les distinguer. La seule identification unique aux stations est l'identification climatologique. Voici comme EC le définit dans son glossaire:

Identifiant (ID) climatologique

L'ID climatologique est un numéro à sept chiffres attribué par le Service météorologique du Canada (SMC) à un site où des observations météorologiques officielles sont effectuées et sert d'identificateur unique et permanent.

Le premier chiffre de l'ID indique la province où se trouve le site d'observation. Les deuxième et troisième chiffres indiquent la zone climatologique de la province.

Lorsque les observations sont interrompues à un site, l'ID n'est pas réutilisé pour les stations subséquentes (qui peuvent ou non différer de nom), à moins que l'on estime que les enregistrements des stations antérieures et subséquentes peuvent être combinés à des fins de climatologie.

Je propose d'utiliser cet identifiant pour distinguer les stations.

Si vous êtes d'accord, comment peut-on utiliser cet identifiant?

1. Est-ce qu'on l'ajoute simplement dans le nom? Dans ce cas, « Bagotville A » deviendrait « Bagotville A (7060400) ».
2. Est-ce qu'on ajoute une propriété? Dans ce cas, je comprends que l'on doit faire la demande dans Wikidata:Propositions de propriétés. Avez-vous des suggestions de sous-catégorie où l'on pourrait faire la demande (Général?, Sciences naturelles?)
3. Est-ce qu'on l'ajoute dans le nom ET comme propriété?

Dirac (talk) 20:41, 1 November 2017 (UTC)

Perso, on parle de combien de stations qui n'ont pas d'identifiants WIGOS ? J'imagine qu'il ne devrait pas être très difficile de demander à l'OMM d'en créer pour ces stations. Je pense que ça vaut l'effort, surtout si on pense étendre le projet à d'autres pays.
Sinon, s'il est impossible de faire autrement que par les identifiants d'EC, alors je pense qu'il faut demander la création de la propriété dans la sous-catégorie "Sciences naturelles". Je pense qu'il faut éviter de compliquer les labels. Perso, de ce que j'ai vu jusqu'ici, les labels de Wikidata doivent être le plus simple possible. Contrairement à Wikipédia, sur Wikidata, les problèmes d'homonymie sont réglés dans les descriptions ou les déclarations des items, pas dans leur titre. --Simon Villeneuve (talk) 01:14, 2 November 2017 (UTC)

Je vais m'informer pour compléter la liste pour les autres stations et vous revenir là-dessus.

Pour les stations sur Wikidata, je réalise qu'on peut utiliser la propriété pour distinguer 2 stations avec le même nom. Par contre, pour WikiCommons, la question demeure entière. Je comprends qu'il ne peut y avoir 2 items avec le même nom, il faudra alors utiliser un second identifiant dans le nom (WMO ou Climate ID). Dirac (talk) 12:54, 2 November 2017 (UTC)

@Simon Villeneuve, VIGNERON:Je viens de renommer

Data:Environnement Canada/Bagotville.tab

pour

Data:Environment Canada/Weather/Bagotville A (71727)/Monthly/Bagotville A (71727) Monthly.tab

et je réalise à ma grande surprise qu'il n'y a pas de redirection... J'imagine que c'est une limitation des données sur Commons? Dirac (talk) 19:14, 6 November 2017 (UTC)

Moi aussi je suis surpris. J'ai le feeling que tout comme pour les catégories, il est impossible de faire des redirections dans cet espace de Commons. Tu peux poser la question à Yurik. Simon Villeneuve (talk) 17:06, 7 November 2017 (UTC)

Wikidata plutôt que Commons

Bonjour,

Je crois que Commons est le plus approprié pour cette masse de données. En effet, Commons joue le rôle d'entrepôt de données, alors que Wikidata est, de façon sommaire, un catalogue. Le contributeur Pasleim mentionne également que Wikidata va planter si le wiki charge cette quantité de données. Dans un premier temps, il faut convaincre la communauté de Commons du bien-fondé du projet, même si les données météo de New York ont été acceptées, parce que le nombre de données est nettement plus vaste (si j'ai bien analysé le dossier) et porte sur beaucoup de stations météo.

Cantons-de-l'Est (talk) 16:51, 22 October 2017 (UTC)

Perso, je ne suis pas sûr qu'obtenir l'aval préalable de la communauté Commons est nécessaire. Le fichier de New York fait environ 80 ko. Si on estime à 100 ko par station météo de EC et que cet organisme possède environ 9 000 stations, ça fait environ 900 Meg, ce qui n'est rien par rapport à l'espace occupé par les autres fichiers de cette banque de fichiers multimédias libre. --Simon Villeneuve (talk) 00:26, 23 October 2017 (UTC)

J'ai une discussion à ce propos avec un responsable de Wikidata et il n'était pas réfractaire à l'idée de mettre les données sur Wikidata. Cela se jouera selon moi sur l'endroit qui donne accès au plus grand nombre de fonctionnalités pour identifier et télécharger les données (voir liste dans la secton #Données bidons).

De plus, l'ordre de grandeur des données pour le Canada, selon ce qu'on décide d'y mettre, peut aller chercher autour de 10 Go, tout au plus. Bien que ça pourrait être gérable sans avertissement sur Commons, je pensais quand même les aviser, histoire qu'ils soient au courant lorsqu'on activera les robots pour injecter les données.

Dirac (talk) 09:16, 24 October 2017 (UTC)

J'en ai discuté avec Yurik, qui semble bien impliqué dans le « projet New York », et il dit qu'une simple annonce sur le Village Pump devrait suffire. Simon Villeneuve (talk) 11:48, 25 October 2017 (UTC)

@Cantons-de-l'Est, Simon Villeneuve, Dirac:

Hummm, c'est un débat récurrent depuis quelques temps, Commons ou Wikidata...

Commons est effectivement peut-être plus adapté pour importer un tableau en un bloc mais pour le moment ce n'est pas encore parfait (impossible de faire une requête SPARL ou même un équivalent).

Je dirais que cela dépend du type de données, de leur quantité (et plus précisément de leur répartition : combien d'affirmations par élément), etc..

Après, rien n'interdit de faire les deux, au contraire c'est peut-être la meilleure solution (avec peut-être les données complètes sur Commons et juste les données essentielles/importantes sur Wikidata).

Cdlt, VIGNERON (talk) 09:36, 24 October 2017 (UTC)

Basé sur cette réponse, je propose d'y aller avec Wikidata. Se pose encore la question du format, que l'on pourrait adapter selon que les observations sont sur une base almanach/mensuelle/quotidienne/horaire. On pourrait faire un exemple pour chacun des types.

Je tiens à souligner que la puissance du calcul est impressionnante: il est rapide de faire la moyenne de toutes les températures. Il faudra faire des tests, mais dans un premier temps ça me semble suffisant pour que ce soit un ajout important par rapport à l'accès aux données brutes.

Dirac (talk) 13:23, 24 October 2017 (UTC)

Je crois que VIGNERON dit plutôt que toutes les données pourraient être placées sur Commons et qu'une partie d'entre-elles pourraient être importées sur Wikidata. Perso, j'adhère à cela. On sait que c'est possible de tout mettre et ré-exploiter sur Commons, alors qu'il y a des doutes pour Wikidata (il faut créer les propriétés manquantes, ce qui n'est pas nécessairement gagné d'avance, et il faut réussir à les ré-exploiter).
Puisque tu sembles plus à l'aise avec le côté SPARQL que Lua, je pense donc qu'il faudrait, dans l'ordre,
1- Convertir les données de EC en fichiers .tab et importer ces derniers sur Commons,
2- Créer les stations météo sur Wikidata, lier celles-ci aux fichiers Commons,
3- Demander la création sur Wikidata d'une propriété météo que l'on juge la plus alléchante/facilement exploitable en SPARQL,
4- Importer les données de cette propriété sur les éléments des stations,
5- Voir le comportement réel de l'outil lorsque l'on effectue différentes requêtes SPARQL sur ces données,
6- Répéter les étapes 3 à 5 pour d'autres propriétés.
Pendant ce temps, rien n'empêche ceux qui se sentent capables avec les graph/Lua de développer des modèles graph/Lua pour exploiter autrement les données des fichiers .tab. Simon Villeneuve (talk) 13:00, 27 October 2017 (UTC)

Simon Villeneuve, je n'ai pas de préférence pour SPARQL vs Lua. C'est plutôt une mauvaise maîtrise des conceptes de ma part. Je comprends de ta réponse qu'il est possible de faire des opérations mathématiques sur WikiCommons via Lua, et sur Wikidata via SPARQL. Si c'est le cas, je n'ai pas de préférence pour l'un ou l'autre et on pourra tester les deux solutions.

Dirac (talk) 11:03, 28 October 2017 (UTC)

En fait, ce que j'essaie de faire comprendre, c'est que l'on sait que la piste Commons fonctionne pour l'acceptation des données et l'exploitation de ces dernières (pour le moment, y a un seul modèle, mais on nous dit que c'est possible d'en faire d'autres), alors que la piste Wikidata est encore à créer (les propriétés n'existent pas encore et on nous dit que le site n'arrive pas à exploiter une grande quantité de données liées à une seule propriété d'un élément). Dans cette optique, l'importation de l'ensemble des données sur Commons me semble prioritaire puisqu'elle ne demande qu'une conversion des fichiers en .tab (et je crois comprendre que ce ne serait pas difficile). Par la suite, on pourrait procéder à une importation progressive des données sur Wikidata pour vérifier si le site est vraiment incapable d'exploiter une grande quantité de données. Par exemple, supposons que nous demandons et obtenons la création de la nouvelle propriété « précipitations » et que nous importons les données mensuelles de Bagotville sur son élément dédié pour, disons, 50 ans. Ça fait 50 x 12 = 600 valeurs pour cette propriété. On pourra faire des requêtes SPARQL (ou dans un autre langage) par la suite pour voir si on arrive à utiliser ces 600 données à partir de Wikidata. Si oui, on vérifie à partir de quelle quantité de données ça chie (genre on ajoute les données quotidiennes de précipitations) et/ou on demande la création d'une autre propriété (genre « température moyenne ») pour faire d'autres tests. Une fois déterminées les limites du système, on regarde s'il y a moyen ou non de repousser ces dernières.
Mon feeling est que pendant que nous ferons tout cela, les modèles exploitant les données de Commons auront évolués et permettront une utilisation étendue sur les autres wikis. --Simon Villeneuve (talk) 11:40, 28 October 2017 (UTC)

Je n'ai pas d'avis tranché mais je sais que 600 valeurs, ce n'est rien du tout pour SPARQL (en tout cas pour le Query Service, j'ai déjà fait de requêtes sur des dizaines de milliers d'éléments, après cela dépend aussi des calculs et de la façon dont les données sont stockées). Le mieux c'est de se servir de l'exemple de Bagotville A (Q42393053) et de tester ;) Cdlt, VIGNERON (talk) 11:55, 1 November 2017 (UTC)

Attention. Je sais bien que le Query Service peut traiter des dizaines de milliers d'éléments. Ici, le problème ne concerne pas le nombre d'éléments à traiter, mais le nombre de déclarations pour UN élément. Vous pouvez avoir un exemple en visitant l'élément qui possède le plus de déclarations : Combined Measurement of the Higgs Boson Mass in p p Collisions at √s=7 and 8 TeV with the ATLAS and CMS Experiments (Q21558717). Je sais pas pour vous, mais pour moi, mon ordi mouline fort seulement pour consulter cette page. Simon Villeneuve (talk) 16:22, 1 November 2017 (UTC)

@Simon Villeneuve: oui mais la consultation de la page on s'en fout un peu, non ? Je veux dire, l'important c'est que cela ne mouline pas sur Wikipédia. En plus cet élément contient 5113 déclarations, largement au-dessus des 600 que tu mentionnes. Pour tester, j'ai mis ci-dessous dessous un requête et un graph sur le nombre de personnes par initiale du prénom des auteurs de cet articles, l'affichage est virtuellement instantané. Cdlt, VIGNERON (talk) 11:22, 6 November 2017 (UTC)

SELECT ?initial (count (?initial) as ?count ) WHERE {
  wd:Q21558717 wdt:P2093 ?value .
  bind (substr(?value, 1, 1) as ?initial)
}
GROUP BY ?initial
ORDER BY DESC(?count)

Try it!

@VIGNERON: Écoute, je ne fais que répéter ce qui a été écrit ici et là. Comment arrives-tu à concilier tes dires avec ça ? --Simon Villeneuve (talk) 11:34, 6 November 2017 (UTC)

@Simon Villeneuve: euh, je ne vois rien de vraiment contradictoire entre mes dires et ceux des pages que tu pointes (si tu penses à After a few hundred statements it UI crashes. je suis d'accord avec cette affirmation, mais je ne vois pas le problème car il me semble que l'on se contrefiche de l'UI et même s'il nous en chaut, dans tout les cas, ce crash n'est visiblement pas bloquant pour les réutilisations). En tout cas, ce qui est sur c'est que SPARQL comme Graph peuvent traiter des dizaines de milliers de triplets, qu'il proviennent de plusieurs ou d'un seul élément Wikidata (et mon exemple ci-dessus le prouve pour le cas le plus extrême dont l'on dispose). Cdlt, VIGNERON (talk) 12:31, 6 November 2017 (UTC)

@Simon Villeneuve, VIGNERON: Je pense que les enjeux sont clairs. Je vous propose de garder cela en tête et voyons ce qu'on peut faire sur Commons dans un premier temps. On verra quelles sont les options selon les problèmes et limitations rencontrés. Dirac (talk) 18:39, 6 November 2017 (UTC)

@Dirac:, ok, pour Commons, du coup, je ne pourrais pas trop vous aider (autant la partie import sur Commons est très simple, autant la ré-utilisation me semble fort compliqué, mais je suis sans doute biaisé par mes limitations en Lua ; en tout cas, je suis incapable de faire en Lua tout ce que je sais faire en SPARQL). De toute façon, une fois les données importées sur Commons, rien n'empêche de les copier ensuite sur Wikidata ; le plus important dans l'immédiat c'est de récupérer les données sous la bonne licence et dans un format manipulable. Cdlt, VIGNERON (talk) 20:02, 6 November 2017 (UTC)

Opération arithmétiques sur les données

Y a-t-il des fonctionnalités pour faire des calculs? Par exemple, peut-on calculer la température historique moyenne pour le mois de juillet à New York? Cette donnée n'est pas dans le tableau, et change à chaque fois que l'on ajoute un mois de données. Ça rendrait le tout dynamique, mais pourrait nécessiter une capacité de calcul énorme côté serveur, selon le calcul demandé. Dirac (talk) 12:29, 23 October 2017 (UTC)

C'est faisable mais avec des outils extérieurs réutilisant Wikidata (par exemple pour une requête SPARQL sur query.wikidata.org ou dans un tableau via un modèle sur une Wikipédia). Je mets un exemple ci-dessous (un peu stupide en terme de logique mais pour démontrer la faisabilité). Cdlt, VIGNERON (talk) 09:41, 24 October 2017 (UTC)

#Moyenne des températures entrées dans Wikidata :
SELECT (avg(?temp) as ?moyenne ) WHERE {
  ?item wdt:P2076 ?temp .
}

Try it!

Sinon (je n'y repense que maintenant) en interne, il existe l'extension graph, qui permet de transformer cette requête (altitude moyenne des communes d'un département, caveat: données partielles) :

SELECT ?dptLabel ( round(avg(?h)) as ?hauteur ) WHERE {
  ?q wdt:P2044 ?h ; wdt:P31 wd:Q484170 ; wdt:P131 ?dpt .
  ?dpt wdt:P31 wd:Q6465 .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "fr". }
}
GROUP BY ?dptLabel

Try it!

En ce diagramme en barre utilisable dont le code peut-être copier-coller sur n'importe quel projet Wikimedia :

Une fois les données présentes, il serait sans doute assez facile de créer un modèle pour ne pas avoir à ré-écrire le code à chaque fois (voir dans un genre différent ce qui est fait sur fr:Pont-l'évêque#Production). Cdlt, VIGNERON (talk) 14:18, 25 October 2017 (UTC)

@VIGNERON:: J'ai montré ce graphique dans une présentation, mais le concept de commune et de département est trop éloigné culturellement du Canada pour que ça marque les esprits. Te serait-il possible d'écrire une requête semblable, mais avec la moyenne des populations des villes canadiennes, classées par province? (J'ai essayé, mais sans succès). Autrement dit:

• Communes de France -> Villes du Canada
• Altitude -> Population
• Département de France -> Province du Canada

Merci, Dirac (talk) 17:23, 27 March 2018 (UTC)

@Dirac: les données sont apparemment incomplètes, j'ai fait provinces et territoires, et je n'ai pas réussi à comprendre quel était l'équivalent de la "commune" au Canada mais voici déjà une première requête:

#defaultView:BarChart
SELECT ?terrLabel ( round(avg(?p)) as ?pop ) WHERE {
  ?q wdt:P1082 ?p ; wdt:P131 ?terr .
  ?terr wdt:P31/wdt:P279* wd:Q2879 .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "fr". }
}
GROUP BY ?terrLabel

Try it!

Cdlt, VIGNERON (talk) 06:52, 28 March 2018 (UTC)

@VIGNERON: Ça va faire le travail, merci. Pour ton information, ça m'a l'air pas mal franco-français comme concept la commune (quoique ça existe aussi en Belgique). Je ne connais pas l'équivalent dans le monde anglo-saxon. On a la ville/village et, pour l'entité supérieure entre la ville et la province, ça dépend vraiment de la législation. Au Québec on a les municipalités régionales de comtés, l'Ontario les counties (pour les détails voir County). Bref, comme le Canada est une fédération, chaque entité est pas mal libre de faire ce que bon lui chante. C'est pour ça que je crois que ton graphique va faire le travail. Merci! Dirac (talk) 12:49, 28 March 2018 (UTC)

@VIGNERON: Autre question: comment fait-on pour avoir le code pour inclure le graphique dans un article (ex: le code qui débute par <graph> ci-haut et qui permet de visualiser le graphique de l'altitude moyenne des communes directement dans cet article? J'ai exploré dans l'interface de Wikidata Query et je ne l'ai pas trouvé. Merci. Dirac (talk) 12:54, 28 March 2018 (UTC)

@Dirac: je connais mal le découpage canadien, c'est pour cela que dans ma requête je demande *tout* ce qui a une population. Du coup, cela fait sans doute une moyenne de population de différent niveaux (faisant donc des doubles comptes) ; je suis preneur de conseil pour améliorer cela. Pour générer le graph, dans Query, il faut choisir la « visualisation » Graph builder, remplir les choix de présentations et enfin cliquer sur Export pour obtenir le code correspondant à l'extension graph (ce code n'étant pas toujours très propre, si il y a un besoin particulier, le mieux est de créer un modèle pour simplifier cela, comme par exemple Template:Graph:Pie chart ou fr:Modèle:graph production utilisé sur fr:Pont-l'évêque#Production). Cdlt, VIGNERON (talk) 17:55, 28 March 2018 (UTC)

@VIGNERON:À ouais... Merci pour l'info pour l'export, je ne m'en serais pas sorti tout seul. Y a-t-il moyen d'avoir un autre ordonnencement sur l'axe des X que l'ordre alphabétique?

Pour la localité, je crois que la manière la plus précise serait d'utiliser municipal government in Canada (Q3788231) et tous les sous éléments. Est-ce que c'est possible ou faut-il absoluement faire une sélection sur une propriété? Dirac (talk) 18:11, 28 March 2018 (UTC)

@Dirac: pour l'ordre, la syntaxe Vega derrière l'extension Graph permet de faire beaucoup de choses (voir https://vega.github.io/) et permet normalement de le gérer comme on le souhaite mais bizarrement, quand on y injecte directement des résultats d'une requête SPARQL, cela semble bloquer sur l'ordre alphabétique. Techniquement, ce doit être possible mais je ne sais pas faire :(

Pas la peine que municipal government in Canada (Q3788231) soit présent sur les éléments visés, on peut demander les sous-classes mais bizarrement quand je le fais, je n'ai plus que 7 barres au lieu de 13 (j'imagine que pour les 6 autres, soit il n'y a pas de municipalités, soit pas de municipalités avec une population, ou bien encore il y a des municipalités avec population mais pas en sous-classe de municipal government in Canada (Q3788231), je te laisse regarder).

#defaultView:BarChart
SELECT ?terrLabel ( round(avg(?p)) as ?pop ) WHERE {
  ?q wdt:P1082 ?p ; wdt:P31/wdt:P279* wd:Q3788231 ; wdt:P131 ?terr .
  ?terr wdt:P31/wdt:P279* wd:Q2879 .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "fr". }
}
GROUP BY ?terrLabel

Try it!

Cdlt, VIGNERON (talk) 18:27, 28 March 2018 (UTC)

@VIGNERON: Semblerait que certains éléments de ville du Canada soit déconnectés J'ai ajouté city or town (Q27676416) comme sous-classe de city (Q515) et je suis en mesure de faire un requête qui semble avoir certaines villes du Canada:

#defaultView:Map
SELECT DISTINCT ?ville ?villeLabel ?pop ?localisation_administrativeLabel ?coordonn_es_g_ographiques WHERE {
  ?ville (wdt:P31/wdt:P279*) wd:Q515.
  ?ville wdt:P17 wd:Q16.
  ?ville wdt:P1082 ?pop.
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
  OPTIONAL { ?ville wdt:P131 ?localisation_administrative. }
  OPTIONAL { ?ville wdt:P625 ?coordonn_es_g_ographiques. }
}
ORDER BY ?pop

Try it!

Curieusement, il y a peu de villes quand on regarde sur la carte mais, après vérifications, c'est parce que la population n'est pas inscrite comme élément. C'est d'ailleurs surprenant le peu de villes ayant une population d'indiquée. Cela dit, serais-tu en mesure d'utiliser cette classification pour faire la moyenne des populations par provinces et territoires? Merci. Dirac (talk) 19:12, 28 March 2018 (UTC)

Requête SPARQL pour les stations météo canadiennes

Serait-il possible de modifier la requête SPARQL suivante afin que le résultat indique instance of (P31) qui prend la valeur de weather station (Q190107) OU de automatic weather station (Q846837)?

SELECT ?item ?itemLabel WHERE
{
  ?item wdt:P31 wd:Q190107 . 
  ?item wdt:P17 wd:Q16 .
   SERVICE wikibase:label { bd:serviceParam wikibase:language "fr". }
}

Try it!

 – The preceding unsigned comment was added by Dirac (talk • contribs).

Voici la requête répondant strictement à ta question :

SELECT DISTINCT ?item ?itemLabel WHERE
{
  { ?item wdt:P31 wd:Q190107 } UNION { ?item wdt:P31 wd:Q846837 } .
  ?item wdt:P17 wd:Q16 .
   SERVICE wikibase:label { bd:serviceParam wikibase:language "fr". }
}

Try it!

Une autre possibilité est de prendre toutes les natures en sous-classes de weather station (Q190107) :

SELECT DISTINCT ?item ?itemLabel WHERE
{
  ?item wdt:P31/wdt:P279* wd:Q190107 .
  ?item wdt:P17 wd:Q16 .
   SERVICE wikibase:label { bd:serviceParam wikibase:language "fr". }
}

Try it!

Actuellement les résultats sont identiques mais à l'avenir il y aura peut-être d'autres types de stations météo.

Sinon, les requêtes actuelles ne récupèrent que l'identifiant Wikidata et le nom en français de la station mais on pourrait récupérer bien d'autres valeurs (les coordonnées, d'autres identifiants, l'altitude, etc.).

Cdlt, VIGNERON (talk) 19:47, 6 November 2017 (UTC)

@VIGNERON: Y a-t-il moyen d'avoir le numéro de la ligne dans une colonne pour les résultats? J'ai fouillé la documentation et, bien que je vois comment on peut ordonner les résultats sur un champ particulier avec "ORDER BY DESC", je ne vois pas comment je peux simplement afficher une colonne avec l'index de ces résultats. Dirac (talk) 16:47, 7 November 2017 (UTC)

@Dirac: excellente question (que je ne m'étais jamais posé, il va falloir que je réfléchisses ou que je demande de l'aide pour trouver la réponse). Si ce n'est pas indiscret et afin que je comprennes mieux : pourquoi veux-tu le numéro de la ligne ? Cdlt, VIGNERON (talk) 17:44, 7 November 2017 (UTC)

@VIGNERON: Je veux illustrer, et diffuser, que la nouvelle mairesse de Montréal, Valérie Plante (Q27959212), est à la tête de la 13e plus grande ville administrée sur la planète. Or, pour illustrer ce quantile, un index serait approprié. Voici le code que je compte utiliser:

#Les plus grosses villes avec une femme maire
#added before 2016-10
#TEMPLATE={"template":"Largest ?c with ?sex head of government","variables":{"?sex":{"query":" SELECT ?id WHERE { ?id wdt:P31 wd:Q48264 .  } "},"?c":{"query":"SELECT DISTINCT ?id WHERE {  ?c wdt:P31 ?id.  ?c p:P6 ?mayor. }"} } }
SELECT DISTINCT ?cityLabel?mayorLabel ?population 
WHERE
{
  BIND(wd:Q6581072 AS ?sex)
  BIND(wd:Q515 AS ?c)

	?city wdt:P31/wdt:P279* ?c .  # find instances of subclasses of city
	?city p:P6 ?statement .            # with a P6 (head of goverment) statement
	?statement ps:P6 ?mayor .          # ... that has the value ?mayor
	?mayor wdt:P21 ?sex .       # ... where the ?mayor has P21 (sex or gender) female
	FILTER NOT EXISTS { ?statement pq:P582 ?x }  # ... but the statement has no P582 (end date) qualifier
	
	# Now select the population value of the ?city
	# (wdt: properties use only statements of "preferred" rank if any, usually meaning "current population")
	?city wdt:P1082 ?population .
	# Optionally, find English labels for city and mayor:
	SERVICE wikibase:label {
		bd:serviceParam wikibase:language "fr" .
	}
}
ORDER BY DESC(?population)
LIMIT 20

Try it!

@VIGNERON: Je suis en train de monter une présentation pour présenter à l'interne d'Environnement Canada pour présenter un projet de collaboration avec Wikimedia Canada, et j'aimerais avoir quelques requêtes SPARQL pour illustrer la puissance de la patente. J'ai discuté avec Simon et comme l'Italie semble être le pays où il y le plus de stations météos, on pourrait montrer comment il est possible d'identifier les stations selon des critères que l'on trouve déjà dans Wikidata.

Le code de Simon pour identifier toutes les stations:

SELECT DISTINCT ?item ?country ?countrylabel WHERE
{
  ?item wdt:P31/wdt:P279* wd:Q190107 .
  ?item wdt:P17 ?country .
           ?country rdfs:label ?countrylabel .
   SERVICE wikibase:label { bd:serviceParam wikibase:language "fr". }
  FILTER((LANG(?countrylabel)) = "fr")
}

Try it!

Accepterais-tu de m'aider à les rédiger?

J'ai pensé à deux requêtes:

1. Liste de toutes les stations météorologiques du Canada d'Italie qui se trouvent à moins de 10 km d'une ville ayant une population de plus de 100 000 habitants;
2. Liste de toutes les stations météorologiques du Canada d'Italie qui se trouvent à moins de 10 km d'un océan de la Méditerranée.

J'aimerais aussi trouver une autre requête reliée à l'agriculture, mais y a rien qui me vient. Aurais-tu une suggestion?

Merci, Dirac (talk) 13:59, 8 March 2018 (UTC)

Graphiques et calculs

@Simon Villeneuve: Je crois qu'on est rendu au point où on peut faire des tests pour l'affichage et les calculs. Voici ce que je propose de faire à partir des données pour Bagotville:

Pour les températures min, max, précipitations et neige, il faudrait faire un graphique présentant:

• Moyenne pour chaque mois (on moyenne toutes les données pour janvier, février, ... pour avoir 12 valeurs moyennées au final)
• Variance
• Écart-type
• Extrêmes (record)

J'ajouterais, pour prouver le concept, l'addition des températures max de New York et de Bagotville pour chaque mois.

Est-ce que c'est quelque chose que tu peux faire à partir du graphique pour les températures de New York, ou encore à partir d'un autre outil?

Dirac (talk) 16:28, 7 November 2017 (UTC)

Ici, tu en es au dernier point du plan de match (« Cibler des articles de Wikipédia en français concernant des localités limitrophes aux stations météorologiques et y apposer des modèles de cartes météorologiques important les données de l'organisme concerné. »). J'ai construit ce dernier selon le principe qu'on importe d'abord les données et on les utilise ensuite. Je peux cependant comprendre que tu veuilles quelques modèles permettant de « vendre » le projet. Cependant, je ne maîtrise pas suffisamment le Lua pour ce faire. Si on regarde le modèle de New York sur Commons, c'est encore Yurik qu'il faut consulter. Sur Wikidata, @VIGNERON: semble être prêt à aider, mais il faudrait importer certaines données sur Wikidata. Je ne sais cependant pas comment spécifier ici que ce serait un test. Lorsque des déclarations sont liées à un élément, celui-ci est automatiquement intégré aux autres éléments de la base de données, ce qui me semble empêcher les éléments « tests/brouillons » avec des données fictives.
Une solution serait d'importer de vraies données climatiques sur « Climat de New York » (Q2979133) et de développer des requêtes SPARQL sur celles-ci. Simon Villeneuve (talk) 17:23, 7 November 2017 (UTC)

@Simon Villeneuve: Il me semble qu'il n'est jamais trop tôt pour réfléchir ;) Ceci dit, ce serait mieux avec des données à manipuler. Je vais voir pour les importer sur Wikidata (par contre, ce serait plutôt sur un élément spécifique station de Central Park ou sur New York City (Q60) - je vois que les données Commons sont liées depuis Q60 - que sur climate of New York (Q2979133), non ? le second élément concerne tout l'État ; et je vais commencer par devoir demander la création).

@Dirac: je vais regarder, pourrais-tu donner quelques précisions sur ce que tu as en tête ?

• Est-ce que tu veux un graphique avec toutes ces informations ou bien un graphique par information ? (je suppose que c'est plutôt le second mais je préfère être sûr que ce n'est pas une superposition comme pour les diagrammes ombrothermiques) sauf erreur, l'habitude est de faire des diagrammes en barre, non ? as-tu des préférences sur les couleurs, la taille, etc. (n'hésite pas à demander, je ferais le tri entre ce qui est possible ou non et comment)
• aurais-tu les formules des calculs ? (pour être sûr que l'on parle de la même chose ; surtout pour les moyennes, on peut moyenner des choses très différentes ;) typiquement : dois-je prendre tout les mois de janvier disponible ou juste les X dernières années ?)

Cdlt, VIGNERON (talk) 18:22, 7 November 2017 (UTC)

@VIGNERON: J'ai ciblé « Climat de New York » car je me suis dit qu'il serait plus facile d'y faire des tests que sur Q60. En effet, je doute que les autres Wikidatiens soient ouverts à « alourdir » Q60 de données météo. Cependant, l'article de frwiki parle de la ville alors que celui de enwiki parle de l'État. C'est probablement une énième différence engendrée par le fait qu'en français, on dit « New York » pour la ville alors qu'en anglais, c'est « New York City », « New York » référant habituellement par défaut à l'État.
La création d'un élément spécifique pour la station météo d'où proviennent les infos du fichier Commons me semble la meilleure solution. Simon Villeneuve (talk) 18:37, 7 November 2017 (UTC)

@VIGNERON:

• Je parle d'un graphique par information en effet. Un diagramme à barre pourrait faire le travail, allons-y avec ça.
• Pour la moyenne, on pourrait faire la somme de tous les mois de janvier, divisés par le nombre de mois, pour avoir la moyenne de l'historique. Un second calcul devrait être sur 30 ans (une convention qui est considéré comme étant une moyenne climatique), les 30 dernières années.

Dirac (talk) 20:35, 7 November 2017 (UTC)

Premiers essais

Voilà, j'ai fait mes premières armes Lua et j'ai gossé des tables contenant les valeurs des fichiers tab en français et en anglais:

• Observations mensuelles
• Monthly observations

Fait cocasse, on remarquera que les tableaux en anglais contiennent également les valeurs impériales. Surprise, le gabarit anglais utilisé met des valeurs impériales par défaut et il est impossible d'afficher uniquement du métrique. On peut voir là une preuve d'un biais américain totalement déplacé.

Prochaine étape, convertir les données de Bagotville pour que le fichier sur Commons reflète vraiment les observations que l'on trouve dans la BD d'EC. Je devrai par la suite adapter les tableaux pour afficher toutes ces informations. Je vous tiens au courant!

Dirac (talk) 19:20, 17 November 2017 (UTC)

Ajout de sous-propriété

@VIGNERON, Simon Villeneuve: je désire faire une demande pour avoir une sous-propriété de weather history (P4150) afin d'avoir les données mensuelles/quotidiennes/horaires. Or, en regardant Property talk:P4150 de même que la page pour la proposition de propriété, j'ai de la difficulté à voir par où je devrais commencer. Est-ce que vous pourriez m'aider pour démarrer dans ce processus? Merci, Dirac (talk) 18:12, 16 November 2017 (UTC)

Je réponds rapidement. Pour le contexte, en ce moment et pour une semaine encore environ, je suis trop occupé mais je compte bien m'y remettre dès que possible.

Pour la demande d'une sous-propriété, je dois avouer que je ne vois pas l'intérêt, Lua devrait suffire, non ? (ou sinon, on devrait pouvoir s'en sortir avec les qualificateurs existants)

Cdlt, VIGNERON (talk) 20:31, 16 November 2017 (UTC)

Ma compréhension, c'est qu'on a besoin d'un discriminant si on veut identifier, par exemple, seulement les observations horaires. Si on n'a pas de sous-propriété, tous les fichiers d'observations seront sous weather history (P4150) et il n'y aura pas moyen de différencier les types d'observations. Est-ce que je me trompe? Dirac (talk) 20:44, 16 November 2017 (UTC)

Perso, de ce que j'en comprends, P4150 est une propriété destinée uniquement à lier un élément à un fichier de données météo sur l'espace Data de Commons. Elle n'est donc pas destinée à accueillir les infos de ce fichier.
Pour intégrer des infos météo sur l'élément d'une station, je crois qu'il faut plutôt suivre la voie montrée par VIGNERON au début de la section Wikidata_talk:WikiProject_Weather_observations#Ajouts des données sur Bagotville A (Q42393053). --Simon Villeneuve (talk) 13:07, 18 November 2017 (UTC)

Je ne comprends pas ce qui est écrit dans cette section... Ça doit expliquer pourquoi je reviens à la charge avec autre chose. Est-ce qu'il y a de la documentation que je pourrais consulter pour comprendre ce que veut dire:

• ⟨ Bagotville A (Q42393053)    ⟩ temperature (P2076) ⟨ 20 ⟩
  point in time (P585) ⟨ 1876-01 ⟩
  applies to part (P518) ⟨ maximum (Q21067467)    ⟩
• ⟨ Bagotville A (Q42393053)    ⟩ precipitation height (P3036) ⟨ 23.9 mm ⟩
  point in time (P585) ⟨ 1876-01 ⟩
  applies to part (P518) ⟨ rain (Q7925)    ⟩
• ⟨ Bagotville A (Q42393053)    ⟩ precipitation height (P3036) ⟨ 0 mm ⟩
  point in time (P585) ⟨ 1876-01 ⟩
  applies to part (P518) ⟨ snow (Q7561)    ⟩

Dirac (talk) 14:46, 18 November 2017 (UTC)

C'est un exemple d'entrée de données. Ainsi, pour le premier, pour entrer une donnée mensuelle de température supérieure sur l'élément, il faut ajouter la propriété P2076 avec la valeur 20 degré celsius et, comme qualifiers, P585 (avec la date du mois de janvier 1876) et P518, indiquant que c'est une valeur supérieure. Je l'ai fait pour que tu puisses voir ce que ça donne. Simon Villeneuve (talk) 12:29, 19 November 2017 (UTC)

Si on procède comme ça, il y aura certaines stations qui auront des dizaines de milliers d'entrées, tout type d'observations confondues. Ça me semble difficilement praticable. Si on fait un fichier par type de données par station sur Commons, ça va donner 3 ou 4 URL vers Commons pour chaque station sur Wikidata, ce qui me semble préférable, du moins dans une première version. Il serait donc possible d'identifier les stations et les URL des données à partir de Wikidata avec du SPARQL dans un premier temps, et traiter les données sur Wikipédia à partir des URL et du Lua dans un deuxième temps. Ne serait-ce pas plus léger ainsi? Dirac (talk) 18:24, 19 November 2017 (UTC)

Schéma de fonctionnement

J'ai fait un premier schéma pour illustrer comment je vois les interactions entre Wikidata/Wikipédia/Commons, de même que les différents scripts et calculs. Vous pouvez les trouvez ici:

• PNG
• SVG

Je vous invite à me donner vos commentaires sur cette proposition. Est-ce comme ça que vous voyez les choses?

Question secondaire: y a-t-il moyen sur Wikidata d'afficher des images comme ont le fait sur Wikipédia? Autrement dit, y aurait-il moyen de voir le schéma affiché directement ici plutôt que de simplement mettre le lien?

Dirac (talk) 22:01, 23 November 2017 (UTC)

Allo,
Pour afficher l'image directement ici, il s'agit simplement de l'importer sur Commons et de faire le lien ici. Simon Villeneuve (talk) 14:46, 13 December 2017 (UTC)

Je peux importer l'image sur Commons, même si c'est un document de travail uniquement pour ce projet? Dirac (talk) 15:15, 13 December 2017 (UTC)

Oui. Simon Villeneuve (talk) 14:45, 15 December 2017 (UTC)

Yé! Comment fait-on pour afficher cette image directement dans cet article?

Dirac (talk) 16:40, 18 December 2017 (UTC)

Hello! This may be relevant to you: https://phabricator.wikimedia.org/T181319 Theklan (talk) 14:25, 5 October 2021 (UTC)

Comme ça:

Relevant property

This new property may be relevant to the interests of this project: METAR code (P5001). NMaia (talk) 13:08, 21 April 2018 (UTC)

Nouvelles propriétés suggérées

@Cantons-de-l'Est, Simon Villeneuve, VIGNERON: Bonjour Messieurs. J'ai fait la demande pour avoir deux propriétés qui permettront de bien identifier les stations météo. C'est surtout le second qui est complexe, le premier n'étant qu'un calque de ce qui a été fait par les Australiens pour Bureau of Meteorology station ID (P3796).

1. Meteorological Service of Canada climate site ID
2. Weather observations data interval

Accepteriez-vous d'y jeter un oeil, notamment pour les éléments créés pour cette propriété (hourly measurement (Q59657010), daily measurement (Q59657036), monthly measurement (Q59657037), periodic climatology data (Q59657033))?

Merci Dirac (talk) 19:23, 12 December 2018 (UTC)

Métadonnées des stations dans Wikidata: projet complété

@Cantons-de-l'Est, Simon Villeneuve, VIGNERON:, j'ai terminé la création des éléments dans Wikidata pour les 8754 stations du SMC. J'ai pas mal tout fait à l'aide du script MSC Weather stations to Wikidata qui créé des entrées en Quick Statement. Ça m'a pris un plus de 50 000 contributions pour en arriver là.

J'ai décrit ce que j'ai fait dans la page du projet à la section Métadonnées des stations d'observations. Accepteriez-vous d'y jeter un oeil et de me donner vos commentaires, que ce soit sur les entrées elles-mêmes ou encore sur la présentation qui en est faite sur la page du projet?

Merci,

Dirac (talk) 19:58, 19 February 2019 (UTC)

Bonsoir Dirac,

J'ai jeté un rapide coup d’œil et globalement cela me semble bon, et même très bon. Félicitations pour ce superbe travail !

J'ai juste remarqué un petit problème, les identifiants WIGOS station ID (P4136) en double (alors que celui-ci est sensé être unique, ce qui déclenche des violations de contraintes listées sur Wikidata:Database reports/Constraint violations/P4136).

Cdlt, VIGNERON (talk) 20:42, 19 February 2019 (UTC)

Bien vu VIGNERON. En regardant la source, je constate qu'il y a plusieurs entrées dans le fichier du SMC avec le même code WIGOS. Par exemple Peace River A (Q61212431) et Peace River A (Q61212432) ont pour entrée (origine du code WIGOS est 71068):

 "PEACE RIVER A","ALBERTA","3075040","2770","71068","YPE","56.23","-117.45","561337000","1172650000","570.9","1944","2014","1955","2014","1944","2014","1944","2007"
 "PEACE RIVER A","ALBERTA","3075041","52258","71068","YPE","56.23","-117.45","561338000","-1172654000","570.9","2014","2019","2014","2019","2014","2019","",""

Ces deux stations ont le même nom, le même WIGOS station ID (P4136), mais des Meteorological Service of Canada climate site ID (P6242) différents. Les autres stations avec des problèmes ont également des MSC ID différents. Puisque cette double utilisation du code WIGOS reflète une celle de la source, et n'a pas été introduite par un problème de conversion, je vais la laisser comme ça. Si jamais ça cause un problème, il sera possible de se tourner vers les SMC pour leur poser des questions à ce sujet. Il sera alors toujours temps de modifier le script pour ajuster les stations problématiques au besoin. Merci, Dirac (talk) 20:14, 20 February 2019 (UTC)

Le mieux est effectivement sans doute de laisser ainsi pour le moment mais je serais curieux d'en savoir plus. J'imagine que (au moins dan certains cas) il ne s'agit de deux postes de mesure au sein de la même station plutôt que vraiment deux stations distinctes (ce que confirme le fait que les deux entrées ont aussi la même coordonnées) mais je préfère ne pas m'avancer plus dans l'hypothèse sans avoir de sources. Cdlt, VIGNERON (talk) 15:40, 22 February 2019 (UTC)

VIGNERON, j'ai contacté les responsables de la liste des stations au SMC, et il a été confirmé que le même ID WIGOS peut être recyclé lorsqu'une station est déménagée. Les identifiants doivent être uniques, mais dans le temps seulement. En d'autres mots, pour les cas problématiques, il faut également spécifier une date en plus de l'identifiant WIGOS pour récupérer la bonne station. As-tu une idée comment on pourrait modifier les contraintes sur l'élément pour refléter cela? Dirac (talk) 15:12, 19 March 2019 (UTC)

Test ping

Dirac
Louis-Philippe Rousseau Lambert
Simon Villeneuve

Notified participants of WikiProject Weather observations
Bonjour,
J'ai modifié le format de la liste des membres du projet pour que nous puissions bénéficier du modèle Ping project. Est-ce que ça fonctionne ?
Sinon, où en est le projet depuis mars ? Simon Villeneuve (talk) 14:17, 30 October 2019 (UTC)

Moi j'ai reçu le ping en tout cas. On a une page de projet sur Meta pour coordonner le tout là-bas. Il faudrait voir avec Peuc s'il a déjà commencé à regarder ça. Dirac (talk) 14:27, 30 October 2019 (UTC)