GW3.0.Alpha ODBC

[jturlier]

Bonjour,
GW3 fonctionne nickel chez moi
Voici la partie intéressante du plugin :

Code : Tout sélectionner

[ODBC]
Server=192.168.0.9
Base=vws
Login=gw
Driver=PostgreSQL Unicode
DSN=
UseDSN=0
Password=j3k=
[MAP]
ODBCUnits=65536
TimeType=1
TimeShift=0
Timestamp=
Date=recdate
DateFormat=%Y%m%d%H%M
Time=
TimeFormat=
DateFieldTypeInteger=0
DateDST=0

Le champ contenant la date ET l'heure est un bigint, tu peux cocher ou non la case "le champ est de type entier"

Question : qu'utilises-tu pour transférer ton fichier dans ta base ?

[endmarsfr]

Bonjour jean,

j'ai utilisé "EMS SQL Manager for potgresql lite".
Il y a une fonction ETL qui permet de charger rapidement un fichier csv en base.

Comme indiqué pour les champs date et time, j'ai du les passer en char(10).
Et avec GW3, j'obtiens une erreur m'indiquant qu'il n'y a pas de fonction SQL "concat".

as-tu installé quelque chose de particulier sur Postgresql ?

d'avance merci.

[jturlier]

Rien ne t'empêche de créer cette fonction,
Si tu as PGAdmin3, tu ouvres une fenêtre de query et tu fais tourner ceci :
CREATE OR REPLACE FUNCTION "concat"(text, text, text) RETURNS text AS '
SELECT $1 || $2 || $3;
' LANGUAGE 'sql';
Attention, ça n'est valide que pour 3 champs. On a là le problème de la conformité de Mysql avec SQL98. Postgresql utilise lui la fonction standard "||" !
En espérant que tu t'en sortes !

[jturlier]

Je viens juste de voir ton message,
quel logiciel pilote utilises-tu pour ta station ?
Ceci select concat('123','234','456') produit '123234456'

[jturlier]

Bonjour jean,
as-tu installé quelque chose de particulier sur Postgresql ?

Comme je te l'ai dit, j'ai un champ UNIQUE pour la date et l'heure dont la structure est AAAAMMJJHHmm

[jturlier]

J'oubliais,
tu as toujours si tu n'y arrives pas, la possibilité de créer une VIEW sur ta table, dans laquelle tu concatènes tes 2 champs, et là, plus de problème non plus !
CREATE VIEW MaMeteo AS
SELECT (madate || monheure) as MaDateHeure, *
FROM meteoactuelle;

Dans GW tu attaques ta view MaMeteo au lieu de ta table meteoactuelle, et tu n'as plus qu'un seul champ à utiliser : MaDateHeure.

[endmarsfr]

Merci Jean pour ton aide.
Je suis parvenu à faire fonctionner graphweather avec postgresql.
Cela m'a permis de diviser par 2 les temps de réponse sur la V2.312b.
Sur la 3.0.2 les résultats semblent moins bons que sur la 3.0.0a.

Je fait là un récap de la procédure utilisée (sachant que j'ai une WMR200 et que j'utilise WSDL au lieu de Xnet).
Tout d'abord comme tu l'as indiqué Jean, il vaut mieux partir d'un champ "datetime" concatené.
cela évite l'usage d'une vue et cela permet de poser un index sur ce champ.

1/
Création de la table :

Code : Tout sélectionner

CREATE TABLE "public"."wxlog" (
  "datetime" CHAR(16) NOT NULL, 
  "Date" DATE NOT NULL, 
  "Time" TIME WITHOUT TIME ZONE NOT NULL, 
  "Baro" REAL, 
  "QNH" REAL, 
  "Gust Speed" REAL, 
  "Gust Dir" INTEGER, 
  "Avg Speed" REAL, 
  "Avg Dir" INTEGER, 
  "Rain Rate" REAL, 
  "Rain" REAL, 
  "UV" REAL, 
  "Temp 0" REAL, 
  "DewPt 0" REAL, 
  "RH 0" REAL, 
  "Temp 1" REAL, 
  "DewPt 1" REAL, 
  "RH 1" REAL, 
  CONSTRAINT "pk_wxlog" PRIMARY KEY("datetime")
) WITHOUT OIDS;

2/ Paramétrage du fichier de config :

Code : Tout sélectionner

...
Date=datetime
DateFormat=%Y-%m-%d %H:%M
Time=
TimeFormat=
...
...

Probe_00=""Baro""
Probe_01=""QNH""
Probe_02=""Rain""
Probe_03=
Probe_04=""Temp 0""
Probe_05=""Temp 1""
Probe_06=""RH 0""
Probe_07=""RH 1""
Probe_08=""DewPt 1""
Probe_09=""Avg Speed""
Probe_10=""Avg Dir""
Probe_11=""Gust Speed""
Probe_12=
Probe_13=
Probe_14=""UV""
Probe_15=
Probe_16=
Probe_17=""Rain Rate""

En remarque, J'ai des noms de champs comprenant des espaces, j'étais passé dans un premier temps par une vue.
Mais il est possible d'utiliser de tels noms de champs dans graphweather en modifiant directement le fichier de config.
Il faut dans ce cas "doubler" les guillemets pour qu'un simple guillemet apparaisse dans les options de grapweather 2.
Et si je paramètre directement les champs dans les options de graphweather avec un guillement, ça fonctionne mais quand on quitte l'appli, le fichier de conf perd ses guillemets et il faut remettre les guillemets à la main.

3/ Pour le chargement des données, j'ai écrit un petit bout de code qui charge les données à partir du fichier wxlog de wsdl directement en BD.
J'ai utilisé une librairie avec un driver postgresql natif (voir la librairie Npgsql.Net : http://pgfoundry.org/frs/?group_id=1000140).
Les perf sont au rdv, 8s pour charger 100000 enregistrements dans une datatable et 8s pour charger les 100000 enregistrements dans la base de données. Beaucoup plus rapide avec ODBC ou je pouvais mettre plusieurs minutes.
Il me reste à l'améliorer pour ne charger que les derniers enregistrements.

J'ai quand même observé quelques "bizarreries" en mode "ODBC" que je n'avait pas avec le fichier CSV.

Avec Graphweather 2 :
J'utilise un facteur de correction pour la vitesse du vent et pour les rafales.
Quand je n'applique pas le facteur de correction, les vitesses sont correctes
Quand j'applique le facteur de correction, les vitesse sont multipliées par le facteur au carré (multipliée 2 x avec le facteur de correction).
Pour l'heure, je pallie en appliquant la racine carrée de mon facteur de correction habituel.
Ce pb n'est pas observé sur Graphweather 3.

Avec Graphweather 3 :
Lorsque j'affiche une période qui correspond à l'année en cours (du 01/01/2011 au /01/01/2012), je n'ai pas d'affichage de données
alors que ça fonctionne avec Graphweather 2 pour la même période.
Pour afficher l'année en cours, avec graphweather, il faut que je sélectionne la période allant du 01/01/2011 au 31/12/2011 pour avoir un affichage de données.


En espérant que cette expérience puisse servir à d'autres.

[jturlier]

J'ai des noms de champs comprenant des espaces, j'étais passé dans un premier temps par une vue

C'est une mauvaise habitude, il est préférable d'utiliser l'underscore (_) au lieu de l'espace dans les noms de champs, ça évite la gymnastique que tu es obligé de faire (et c'est conforme aux normes habituelles... mais rien ne t'empêche de continuer !!!)
Second point, ton champ datetime, pour améliorer encore tes temps de réponse, il est préférable de supprimer les /,espaces et : pour en faire un champ de type AAAAMMJJHHmm (qui est tout aussi lisible), ce qui te permet de définir ce champ en bigint au lieu de caractères. (Travail plus rapide sur ta clé primaire)
Troisième point, pourquoi reste-t-il un date et time en forrmat SQL ? (C'est inutilisable avec GW ou alors avec des acrobaties). en plus, évite d'utiliser des mots réservés (date, time) en temps que noms de champs. (ça non plus ce n'est pas bien )
Quatrième point, gust dir dans ta table et avg dir dans la conversion Champs SQL -> probes ? D'ailleurs, s'il s'agit d'une moyenne, je ne comprends pas trop l'utilisation d'un integer puiqu'il risque d'y avoir des décimales.

Beaucoup plus rapide avec ODBC ou je pouvais mettre plusieurs minutes.
Il me reste à l'améliorer pour ne charger que les derniers enregistrements.

Les drivers natifs sont toujours plus rapides.
Si tu essaies d'insérer des enregistrements déjà existants sur des clés ou index uniques, PG est obligé de les traiter en erreur et cela alourdi le traitement et dégrade les temps de réponses.

Avec Graphweather 2 :
J'utilise un facteur de correction pour la vitesse du vent et pour les rafales.
Quand je n'applique pas le facteur de correction, les vitesses sont correctes
Quand j'applique le facteur de correction, les vitesse sont multipliées par le facteur au carré (multipliée 2 x avec le facteur de correction).
Pour l'heure, je pallie en appliquant la racine carrée de mon facteur de correction habituel.
Ce pb n'est pas observé sur Graphweather 3.

Il serait bon que là tu joignes le fichier de config "complet" de ton plugin (en Zip Stp, ça prend trop de place en

Code : Tout sélectionner

)
[quote="endmarsfr"]Les perf sont au rdv, 8s pour charger 100000 enregistrements dans une datatable et 8s pour charger les 100000 enregistrements dans la base de données.[/quote]
Qu'as-tu voulu dire ? Pour moi ça signifie la même chose !
[quote="endmarsfr"]En espérant que cette expérience puisse servir à d'autres.[/quote]
Tous les retours d'informations sont toujours bons à prendre et on y découvre toujours quelque chose d'intéressant !

Jean

[endmarsfr]

Bonjour Jean,

C'est une mauvaise habitude, il est préférable d'utiliser l'underscore (_) au lieu de l'espace dans les noms de champs, ça évite la gymnastique que tu es obligé de faire (et c'est conforme aux normes habituelles... mais rien ne t'empêche de continuer !!!)
Second point, ton champ datetime, pour améliorer encore tes temps de réponse, il est préférable de supprimer les /,espaces et : pour en faire un champ de type AAAAMMJJHHmm (qui est tout aussi lisible), ce qui te permet de définir ce champ en bigint au lieu de caractères. (Travail plus rapide sur ta clé primaire)
Troisième point, pourquoi reste-t-il un date et time en forrmat SQL ? (C'est inutilisable avec GW ou alors avec des acrobaties). en plus, évite d'utiliser des mots réservés (date, time) en temps que noms de champs. (ça non plus ce n'est pas bien )
Quatrième point, gust dir dans ta table et avg dir dans la conversion Champs SQL -> probes ? D'ailleurs, s'il s'agit d'une moyenne, je ne comprends pas trop l'utilisation d'un integer puiqu'il risque d'y avoir des décimales.

Pour le premier point tu as raison, l'underscore est préférable.
Les champs du fichier CSV sont nommés de cette façon, je joins un extrait.
Je pourrais faire un mapping entre les noms de champs du fichier CSV et les nouveaux de la table.

Pour le champs AAAAMMJJHHmm, tu as encore raison. Cela sera plus performant.
J'ai conservé les champs date et time, cela m'évite d'autres conversion avec d'autres applications.

Les champs gust dir et avg dir (sont les directions du vent et de la rafale et sont exprimés en degrés et sont bien des entiers dans le fichier).

endmarsfr a écrit:
Avec Graphweather 2 :
J'utilise un facteur de correction pour la vitesse du vent et pour les rafales.
Quand je n'applique pas le facteur de correction, les vitesses sont correctes
Quand j'applique le facteur de correction, les vitesse sont multipliées par le facteur au carré (multipliée 2 x avec le facteur de correction).
Pour l'heure, je pallie en appliquant la racine carrée de mon facteur de correction habituel.
Ce pb n'est pas observé sur Graphweather 3.

Il serait bon que là tu joignes le fichier de config "complet" de ton plugin (en Zip Stp, ça prend trop de place en

Code : Tout sélectionner

)
[/quote]
OK, c'est en PJ
Indiques moi, stp, si toi aussi, tu rencontres les bizarreries mentionnées

[quote]
endmarsfr a écrit:
Les perf sont au rdv, 8s pour charger 100000 enregistrements dans une datatable et 8s pour charger les 100000 enregistrements dans la base de données.
Qu'as-tu voulu dire ? Pour moi ça signifie la même chose !
[/quote]
Simplement, que je mets 8s pour charger le contenu du fichier dans un objet "local" .Net qui est appelé "Datatable".
Cette étape, me permet justement de rejeter les doublons bcp plus vite qu'avec la BD, de faire le traitement permettant de "merger" les champs date et time.
Ensuite suite, l'objet datatable est chargé en 8s dans la BD via un traitement type COPY.
Comme indiqué, il me reste à l'améliorer pour mettre dans un fichier de conf des paramètres 
 - pour ne recharger que les dernières données et pas la totalité de la BD. 
 - pour mettre un place un mapping et un typage des champs dans le fichier de conf.


en tout cas, encore merci de ta patience, 
Pour moi c'est surtout une première tentative pour valider le bon fonctionnement de GW avec PGSQL.
je suis plutôt content du temps de chargement, car j'avais précédemment utilisé un outil du commerce '(EMS SQL Manager lite) pour charger les données et cela avait pris plus 3 minutes pour les 100000 enregistrements.
Je vais poursuivre dans cette voie, car en plus des perf apportées, ça permet de manipuler massivement et facilement les données.


Bonne journée.

[jturlier]

As-tu des raisons particulières d'activer des corrections individuelles de sondes ?
[CALIBRATION_BASE_2]
Used=1
Slope=1.000000
Intercept=2.000000
Low=0.000000
Hi=100000.000000

[CALIBRATION_BASE_9]
Used=1
Slope=1.362200
Intercept=0.000000
Low=0.000000
Hi=183.014999

[CALIBRATION_BASE_11]
Used=1
Slope=1.362200
Intercept=0.000000
Low=0.000000
Hi=183.014999
Je ne rencontre aucune des bizarreries comme tu dis, mais je n'ai aucune raison de modifier le calibrage des sondes.

Simplement, que je mets 8s pour charger le contenu du fichier dans un objet "local" .Net qui est appelé "Datatable".
Cette étape, me permet justement de rejeter les doublons bcp plus vite qu'avec la BD, de faire le traitement permettant de "merger" les champs date et time.
Ensuite suite, l'objet datatable est chargé en 8s dans la BD via un traitement type COPY.

OK, je comprend ce que tu veux dire, c'est très lié au fait que tu utilises un programme "banalisé" qui a des contraintes. A la différence, j'utilise mon propre programme de chargement en vb.net et je sais toujours quel est le dernier enregistrement dans ma table : je lis le fichier en ignorant tout jusqu'à la ligne correspondante, et ensuite je commence à charger. En fait je viens aussi tester toutes les minutes si la date du fichier a changé pour activer ou non le traitement de transfert dans la table.

J'espère avoir répondu à la plupart de tes interrogations. N'hésite pas si tu as des questions ou si tu veux certains de mes codes.

Jean

[endmarsfr]

As-tu des raisons particulières d'activer des corrections individuelles de sondes ?
[CALIBRATION_BASE_2]
Used=1
Slope=1.000000
Intercept=2.000000
Low=0.000000
Hi=100000.000000

[CALIBRATION_BASE_9]
Used=1
Slope=1.362200
Intercept=0.000000
Low=0.000000
Hi=183.014999

[CALIBRATION_BASE_11]
Used=1
Slope=1.362200
Intercept=0.000000
Low=0.000000
Hi=183.014999
Je ne rencontre aucune des bizarreries comme tu dis, mais je n'ai aucune raison de modifier le calibrage des sondes.

J'espère avoir répondu à la plupart de tes interrogations. N'hésite pas si tu as des questions ou si tu veux certains de mes codes.

Jean

pour les calibration, j'applique un coefficient de correction pour la vitesse du vent.
Comme mon mat n'est pas à 10m, je simule une vitesse de vent à 10m avec celle mesurée à la hauteur de mon mat.
Pour les précipitations, j'ai appliqué une correction pour normaliser les résultats de GW avec un autre outil ou j'avais un écart de 2mm.

Merci pour ton offre, j’apprécierais effectivement de voir certains codes.

Pour ma part, j'ai quelques outils aussi, que je peux mettre également à dispo.

j'ai refais un outil d'envoi massif sur WUnderground
Car à l’époque, celui de GW plantait, le mien donne la possibilité de renvoyer sur WUnderground les données sur période donnée passée et d'effacer et de modifier les données sur WUnderground.
J'ai aussi fais une petite moulinette pour récupérer les données envoyées sur WUnderground dans fichier.
cela m'a été utile pour récupérer mes données quand j'ai perdu mon disque il y a quelques semaines.

Je vais faire évoluer ces outils pour que les données puissent être récupérées depuis une BD, alors qu'aujourd'hui, je lit un fichier csv.
A ce sujet, j'utilise un bon fwk pour manipuler les CSV (LumenWorks.Framework.IO.Csv).

Je vais continuer à regarder pourquoi la calibration ne marche pas bien.
Ce qui est bizarre, c'est que avec les CSV je n'avais pas de soucis même avec la calibration activée, quand je désactive la calibration, les données affichées sont cohérentes et avec GW3 cela fonctionne correctement.

A bientôt