Probleme interpretation des donnees.

[SYO2]

Bonjour.
Mon software de navigation SeaPro 3000 performance sailing (version 8.404) interprete le fichier ci joint intitule 20120223_172816_.grb.bz2 comme indique dans le second fichier joint intitule Capture.JPG .
J·ai contacte le service de développement d·Euronav avec lequel j·entretiens d·excellentes relations faisant partie de leur équipe de test.
Voici ci après le résultat de notre echange de correspondance:
MOI a Euronav
Date: 2012/2/23
Subject: Waves in the Med
To: Brian Euronav Voilier XXX
Hi Brian.
Quite odd.
The attached file include Sig WH, Max WH, Direction and Period.
It comes from Zygrib.
Interpretation given by Seapro is as per image.
EURONAV a moi
HI Claude,
seaPro just uses the published GRIB data id numbers to decide what the data is , have checked and these are interpreted correctly.
i.e.
100 Sig Waves and swell
207,208,220 are as per the GRIB specification (as given by seaPro)
Have downloads the zygrib grib program and that only recognises the significant wave height correctly.
Maximum wave height is shown as arrows.
So they don't seem to be getting their data correct!
Best regards
Brian

Qui peut aider a ce que les "ID numbers" soient concordants?
Merci d·avance.

[jza]

Bonjour.

EURONAV a moi
HI Claude,
seaPro just uses the published GRIB data id numbers to decide what the data is , have checked and these are interpreted correctly.
i.e.
100 Sig Waves and swell
207,208,220 are as per the GRIB specification (as given by seaPro)

Ben non, les identifiants de données ne sont pas "interpreted correctly" par MachinPro,
même avec un Pro dans le nom pour épater la galerie,
même en affirmant avec une assurance prétentieuse avoir "checked" je ne sais quoi,
même en éludant les problèmes en évitant surtout de se remettre en cause.

Les spécifications GRIB sont loin d'être aussi simplistes, d'où la grande souplesse du format,
mais aussi la foultitude de logiciels qui font n'importe quoi car programmés par des olibrius qui
n'ont rien cherché à comprendre (c'est vrai que c'est bien lourd à lire une norme, mais bon,
quand on se prétend Pro avec une majuscule on pourrait espérer un peu plus de rigueur).

Les identifiants de données ne sont pas figés par la norme, mais dépendent du centre météo d'origine
des données, en particulier à partir de 128. Il faut donc ajuster à la volée les tables de correspondances,
et c'est pas une mince affaire tellement il y a de variantes.

C'est pour cela que zyGribPasPro refuse d'afficher les gribs dont il n'a pas réussi a identifier de façon sûre la provenance,
alors qu'on dirait que d'autres préfèrent afficher n'importe quoi plutôt que de prendre la peine de vérifier la cohérence des paramètres.

Ça me rappelle MaxMachin qui n'a pas compris que sur une planète sphérique le nord n'est pas forcément "en haut",
et qui affiche les gribs à l'envers une fois sur deux sans même vérifier l'orientation des données, bien sûr sans se remettre en cause.

Pour en finir : utilisez plutôt OpenCPN pour naviguer http://opencpn.org, ce n'est pas programmé avec des œillères,
ce n'est pas limité à windows, c'est libre, et les bugs sont corrigés quand ils sont signalés.

[SYO2]

Bonjour.

EURONAV a moi
HI Claude,
seaPro just uses the published GRIB data id numbers to decide what the data is , have checked and these are interpreted correctly.
i.e.
100 Sig Waves and swell
207,208,220 are as per the GRIB specification (as given by seaPro)

Ben non, les identifiants de données ne sont pas "interpreted correctly" par MachinPro,
même avec un Pro dans le nom pour épater la galerie,
même en affirmant avec une assurance prétentieuse avoir "checked" je ne sais quoi,
même en éludant les problèmes en évitant surtout de se remettre en cause.

Les spécifications GRIB sont loin d'être aussi simplistes, d'où la grande souplesse du format,
mais aussi la foultitude de logiciels qui font n'importe quoi car programmés par des olibrius qui
n'ont rien cherché à comprendre (c'est vrai que c'est bien lourd à lire une norme, mais bon,
quand on se prétend Pro avec une majuscule on pourrait espérer un peu plus de rigueur).

Les identifiants de données ne sont pas figés par la norme, mais dépendent du centre météo d'origine
des données, en particulier à partir de 128. Il faut donc ajuster à la volée les tables de correspondances,
et c'est pas une mince affaire tellement il y a de variantes.

C'est pour cela que zyGribPasPro refuse d'afficher les gribs dont il n'a pas réussi a identifier de façon sûre la provenance,
alors qu'on dirait que d'autres préfèrent afficher n'importe quoi plutôt que de prendre la peine de vérifier la cohérence des paramètres.

Ça me rappelle MaxMachin qui n'a pas compris que sur une planète sphérique le nord n'est pas forcément "en haut",
et qui affiche les gribs à l'envers une fois sur deux sans même vérifier l'orientation des données, bien sûr sans se remettre en cause.

Pour en finir : utilisez plutôt OpenCPN pour naviguer http://opencpn.org, ce n'est pas programmé avec des œillères,
ce n'est pas limité à windows, c'est libre, et les bugs sont corrigés quand ils sont signalés.

Merci de votre réponse qui sans aucun doute intéressera Euronav.
Elle ne résout malheureusement pas mon problème car a mon grand regret après avoir teste pendant un an le logiciel que vous proposez je ne suis jamais parvenu (mais je reconnais que je ne suis pas un informaticien) a faire un routage minimum en utilisant les infos vent sur maille fine de Coamps, ni a intégrer mes polaires up et down wind (que je travaille depuis 6 ans) ni a trouver la manière de créer un interfaçage correct (résultats de calculs du programme de navigation envoyés aux écrans des instruments) avec mes 4 écrans Tactick.
Conclusions: je garde mon fantastique SeaPro pour naviguer et lire les fichiers que je retire de SailDocs , tout en espérant encore pouvoir retirer un jour les VAGUES par email sur mon adresse WINLINK chez vous et les lire alors sur votre software.

[brianm101]

Bonjour,

seaPro uses the data ID's given in the GRIB specification. Agree that the data ID's 128-254 are reserved for the originating data centre. As we don't know the the internal usages of the local data centres (they can change them whenever they like!) - seaPro uses the default ones given in the specification for NWS/NCEP (US National Weather Service), which works ok for most commercial GRIBS. Although commercial GRIBS tend to output data ID's below 128 for obvious reasons.

seaPro is designed so that it can display data irrespective of what it is (you can alter how an item is displayed). The only data it can't processes is data with unknown u and v pairs (vector data) in the 128-254 range as these require processing together, such as wind direction and speed (which is below 128!).

For the marine navigator just about all the required GRIB data is covered by the defined data id's 1 to 127, so there is no good reason why providers can't stick to this for marine use (and most do)!

Note: With reference to the openCPN comment - it doesn't do any better, it can only display Significant Wave height! In fact it can only display 6 types of data - which is probably fine for most users

If you have a list of your data in the range 128-254 could look at implementing - presume this is using ID's from Toulouse (RSMC) or do you add your own?

[SYO2]

Bonjour,

...
If you have a list of your data in the range 128-254 could look at implementing - presume this is using ID's from Toulouse (RSMC) or do you add your own?

J·imagine qu·une telle offre de collaboration ne restera pas lettre morte???

[brianm101]

Bonjour

Non!

seaPro uses a lookup table to look up meaning and to assign a default display modes. So for simple scalar data such as a height, pressure etc., it should not be too difficult, for paired U/V vector data it might require a bit more work!

(seaPro utilise une table de consultation pour rechercher un sens et d'attribuer un mode d'affichage par défaut. Pour les données scalaires simples tels que la hauteur, la pression ne devrait pas être trop difficile, pour appariés données vectorielles U / V, il pourrait avoir besoin de travail un peu plus! )

[SYO2]

Bonjour

Non!

seaPro uses a lookup table to look up meaning and to assign a default display modes. So for simple scalar data such as a height, pressure etc., it should not be too difficult, for paired U/V vector data it might require a bit more work!
...

Hi.
My comment was not adressed to you but to the Zygrib developpers as I know that you can·t do better if you don·t receive the table of the id·s they use.
Thanks for your efforts on behalf of the users of your WONDERFUL software.
It is of real help to plan my (as fast and thus as short as possible) passages and to check permanentaly if my sails are well trimmed...

[SYO2]

Bonjour,

...
If you have a list of your data in the range 128-254 could look at implementing - presume this is using ID's from Toulouse (RSMC) or do you add your own?

J·imagine qu·une telle offre de collaboration ne restera pas lettre morte???

Hello jza.
Etes vous en conge?
Nautiquement vôtre.

[SYO2]

Bonjour.
...
Les identifiants de données ne sont pas figés par la norme, mais dépendent du centre météo d'origine
des données, en particulier à partir de 128. Il faut donc ajuster à la volée les tables de correspondances,
et c'est pas une mince affaire tellement il y a de variantes.

C'est pour cela que zyGribPasPro refuse d'afficher les gribs dont il n'a pas réussi a identifier de façon sûre la provenance,
alors qu'on dirait que d'autres préfèrent afficher n'importe quoi plutôt que de prendre la peine de vérifier la cohérence des paramètres

...

Bonsoir.
As I can·t see up to now any answer to the interesting offer made by Euronav to study how their software could read your data I wonder to know if there is a real list of data identifiers used by Zygrib with numbers above 128 and up to 254 and/or if this list can only be used by OpenCPN ?
Je remercie d·avance jza pour sa réponse qui le cas échéant clôturerait définitivement ce post.

[jza]

Bonjour,

As we don't know the the internal usages of the local data centres (they can change them whenever they like!) - seaPro uses the default ones given in the specification for NWS/NCEP (US National Weather Service),

It's a totally irresponsible choice

which works ok for most commercial GRIBS.

It's false.

Although commercial GRIBS tend to output data ID's below 128 for obvious reasons.

It's false

It's not my problem, but looks like you really do not understand what a grib file is.

[jza]

Bonjour,

...
If you have a list of your data in the range 128-254 could look at implementing - presume this is using ID's from Toulouse (RSMC) or do you add your own?

J·imagine qu·une telle offre de collaboration ne restera pas lettre morte???

Vous imaginez mal.

zyGrib est un logiciel libre, opensource, distribué sous la licence libre GPL.

Il est hors de question pour zyGrib de collaborer avec un produit commercial programmé de façon obscure, et de surcroit limité à un seul système d'exploitation lui aussi non libre.

Si du code de zyGrib est incorporé dans un autre logiciel, il doit lui aussi respecter la licence GPL.

[jza]

Hello jza.
Etes vous en conge?
Nautiquement vôtre.

J'ai l'impression que vous n'avez pas bien compris le contexte.

zyGrib est développé par une toute petite équipe de bénévole, sur le peu de temps libre dont ils disposent.
Par choix, il est distribué gratuitement, malgré la mise en place d'un serveur d'un coût non négligeable pour avoir la puissance de calcul nécessaire.

Dans ces conditions, il serait de bon ton que vous cessiez de faire la promotion de logiciels commerciaux sur ce forum mis gracieusement à votre disposition,
il y a certainement des endroits mieux adaptés.

D'autre part, personne ne se doit de répondre dans l'immédiat à vos injonctions.
On a parfois mieux à faire dans notre vie que de céder séance tenante à votre impatience.

[SYO2]

Hello jza.
Etes vous en conge?
Nautiquement vôtre.

Dans ces conditions, il serait de bon ton que vous cessiez de faire la promotion de logiciels commerciaux sur ce forum mis gracieusement à votre disposition, ...

J·en prends bonne note.