Bug: Décalage en longitude avec fichier GRIB

[Photophore]

Bonjour,

quand on lit un fichier issu du serveur Zygrib (*.bz2), l'affichage des carrés colorés de vent est parfaitement ajusté en latitude/longitude.
Mais quand on ouvre avec Zygrib, un fichier Grib issu du site Grib.US (*.grb), les carrés de vent sont décalés en longitude.

Ex. avec Zygrib 3.8.5.2 sur Win XP: pour une zone située aux alentours de 42°N, 140°W, il y a un décalage d'environ 6' en longitude vers l'Est, dans l'affichage des carrés de vent.

Hypothèse: il y a peut-être une correction de longitude qui est faite dans la préparation des vents sur le serveur Zygrib et qu'il faudrait appliquer dans l'application Zygrib dans le cas où on ouvre un fichier .grb

A+

[jza]

Bonjour
Maintenant l'envoi de pièces jointes avec les messages est activé (mais pas encore testé, c'est l'occasion).
Merci de joindre le fichier grib décalé pour analyser le problème.

[Photophore]

Bonjour
Maintenant l'envoi de pièces jointes avec les messages est activé (mais pas encore testé, c'est l'occasion).
Merci de joindre le fichier grib décalé pour analyser le problème.

Voilà le fichier GRIB (j'ai du le zipper car l'extension grib n'était pas autorisée par la fonction Pièce attachée).

Bonne analyse,
Pascal

[jza]

Voilà le fichier GRIB

C'est le fichier qui est "décalé", pas l'affichage dans zygrib.

Voici le résultat de wgrib (analyseur et décodeur de grib fourni par le NOAA, l'un des organismes à l'origine de la normalisation du format grib) :

Code: Select all

rec 1:0:date 2010032100 UGRD kpds5=33 kpds6=105 kpds7=10 levels=(0,10) grid=255 10 m above gnd anl:
  UGRD=u wind [m/s]
  timerange 10 P1 0 P2 0 TimeU 1  nx 25 ny 8 GDS grid 0 num_in_ave 0 missing 0
  center 7 subcenter 0 process 81 Table 2 scan: WE:NS winds(N/S) 
  latlon: lat  45.000000 to 38.000000 by 1.000000  nxny 200
           long -145.900000 to -121.900000 by 1.000000, (25 x 8) scan 0 mode 128 bdsgrid 1
  min/max data -2.15445 14.2065  num bits 16  BDS_Ref -215.445  DecScale 2 BinScale -5

Ce fichier contient donc des données qui vont de 121,9°W à 145,9°W par pas de 1° en longitude.
Zygrib respecte ces paramètres de grille spécifiés dans l'entête des enregistrements.
Il est donc normal d'avoir un décalage de 0,1°=6' par rapport aux longitudes entières, en considérant que le fichier respecte bien les conventions de définition des grilles de la norme du format grib.

j'ai du le zipper car l'extension grib n'était pas autorisée par la fonction Pièce attachée).l

Gros progrès, on peut maintenant poster des fichiers .grb et .grib, ouf

[Photophore]

C'est le fichier qui est "décalé", pas l'affichage dans zygrib.
Ce fichier contient donc des données qui vont de 121,9°W à 145,9°W par pas de 1° en longitude.
Zygrib respecte ces paramètres de grille spécifiés dans l'entête des enregistrements.
Il est donc normal d'avoir un décalage de 0,1°=6' par rapport aux longitudes entières, en considérant que le fichier respecte bien les conventions de définition des grilles de la norme du format grib.

Bien vu pour le décalage de 0,1°.
Le principe choisi de représenter des carrés à partir de la borne ouest du fichier est un peu piégeur (Il vaudrait mieux, à mon avis, toujours plaquer les données de vent sur une grille fixe de 1 ou 0,5 degré de coté) mais si le programme a été conçu ainsi, on s'en contentera.
Il faudra seulement que je me souvienne d'être vigilant en ouvrant des fichiers .grb avec Zygrib.

A+
Pascal

[jza]

Le principe choisi de représenter des carrés à partir de la borne ouest du fichier est un peu piégeur (Il vaudrait mieux, à mon avis, toujours plaquer les données de vent sur une grille fixe de 1 ou 0,5 degré de coté)

Je ne suis pas d'accord, ou alors j'ai mal compris.

Le fichier contient des infos comprises entre 121,9°W à 145,9°W, donc le programme affiche des valeurs dans cette zone.
Je ne vois vraiment pas ce qu'il y a de piégeux dans ce comportement.

En suivant votre raisonnement il faudrait inventer des valeurs entre 146°W et 145,9°W et afficher n'importe quoi pour boucher le trou,
ou bien commencer à afficher à 145°W et perdre presque 1° de valeurs... j'ai du mal à percevoir l'intérêt de cela.

Le problème vient peut-être plutôt de l'autre côté :
pourquoi générer un fichier non aligné sur des 1/2° à partir d'un modèle dont la grille est elle-même alignée sur des 1/2° ?
Le serveur de fichiers grib de zygrib ne permet pas cela.

[Gilletarom]

Bonjour,
Bonjour,

Je saute d'un forum à l'autre et je découvre que le problème de l'affichage des fichiers grib et de leur contenu est sacrément complexe. Cela fait deux galères, une ici et l'autre sur le second forum.

Il me semble que l'établissement d'une FAQ qui expliquerait tout cela s'impose et avec mise en ligne sur le site web de zygrib, mais aussi dans le logiciel lui même pour éviter des emplois absurdes des fichiers grib venant d'autres services.

Sans compter que tout cela nuit gravement à la crédibilité :
- d'une part dans les logiciels météo comme zygrib ou ugrib ou ....
- d'autre part dans les logiciels de carto graphique qui sont censés être capable d'afficher les fichiers grib.

Cordialement,

Gilletarom.

[jza]

Je saute d'un forum à l'autre et je découvre que le problème de l'affichage des fichiers grib et de leur contenu est sacrément complexe. Cela fait deux galères, une ici et l'autre sur le second forum.

Oui c'est un format complexe, parce que la météo c'est complexe et qu'il faut représenter des trucs qui évoluent en 3D dans l'atmosphère autour d'une terre toute biscornue.
Le format grib permet de stocker pratiquement toutes les données météo et la façon dont elles évoluent dans l'espace et dans le temps, le tout calé sur toutes les combinaisons de grilles imaginables.
Le prix à payer de cette universalité, c'est qu'il faut décrire précisément ce que le fichier contient pour qu'il soit exploitable. C'est simple à comprendre, pas bien compliqué à mettre en place pour les données simples (grilles rectangulaires), mais apparement c'est encore trop compliqué pour quelques éditeurs de fichiers gribs.

Il me semble que l'établissement d'une FAQ qui expliquerait tout cela s'impose et avec mise en ligne sur le site web de zygrib, mais aussi dans le logiciel lui même pour éviter des emplois absurdes des fichiers grib venant d'autres services.

Oui, une doc et une faq deviennent indispensables, mais je n'ai absolument pas le temps de m'en occuper, ni le goût, et il ne faudrait pas que le développement de zygrib devienne une corvée.

Je pense mettre en place un wiki (un jour), en espérant que les utilisateurs le rempliront, tout comme j'espère qu'ils répondent quand ils le peuvent aux questions posées sur le forum.
Je ne souhaite surtout pas qu'une doc soit éditée sous la forme d'un pdf et diffusée. Ce serait le meilleur moyen d'en retrouver plein de versions obsolète sur internet, au moins dans un premier temps.

Sans compter que tout cela nuit gravement à la crédibilité :
- d'une part dans les logiciels météo comme zygrib ou ugrib ou ....
- d'autre part dans les logiciels de carto graphique qui sont censés être capable d'afficher les fichiers grib.

Pas de temps à perdre à se battre contre les habitudes et les croyances de ceux qui ne voient pas plus loin que le bout de leur nez, c'est perdu d'avance mais c'est pas grave.

[Gilletarom]

Oui, une doc et une faq deviennent indispensables, mais je n'ai absolument pas le temps de m'en occuper, ni le goût, et il ne faudrait pas que le développement de zygrib devienne une corvée.

Je pense mettre en place un wiki (un jour), en espérant que les utilisateurs le rempliront, tout comme j'espère qu'ils répondent quand ils le peuvent aux questions posées sur le forum.
Je ne souhaite surtout pas qu'une doc soit éditée sous la forme d'un pdf et diffusée. Ce serait le meilleur moyen d'en retrouver plein de versions obsolète sur internet, au moins dans un premier temps.

Je remarque que le wiki de OpenCPN se remplit doucement mais surement. Alors, pourquoi pas pour zyGrib ! C'est une bonne idée. Au pire vous pourriez avoir besoin d'un modérateur pour vous apporter de l'aide.