Altitude relative de cloud_base

[slyworld]

Bonsoir !

je suis un utilisateur de graphweather v2 depuis bientôt 2 ans et en trainant sur ce forum, j'ai découvert aujourd'hui la "variable" cloud_base. la trouvant tres interressante, je l'ai mis en œuvre sur un de mes graph et apres quelques reflexions, je me suis rendu compte que, visiblement, elle indiquait une altitude relative a l'altitude de la station et non pas une altitude par rapport au niveau de la mer.

exemple : cloud_base me renvoit en ce moment meme l'altitude de 165m ..... ma station est positionné sur le toit de ma maison qui se trouve a ..... 1700m ! et je vous garantie que je ne suis pas dans les nuages

j'ai bien essayé de corriger manuellement le probleme en additionnant le resultat de cloud_base a mon altitude mais, a la lecture de plusieurs post, je me suis rendu compte que les opérations mathématiques était impossible dans les fichiers XML de graphweather....

ma question est donc : y a t'il un moyen de corriger cela et si non, serait-il possible de corriger le probleme dans le logiciel ?

dans l'attente d'une réponse,

merci de m'avoir lu et toutes mes félicitations au concepteur de ce superbe logiciel !

[paaubert]

Salut,

Cette information d'altitude des nuages est très approximative, mais je ne vois pas pourquoi tu aimerais l'altitude au niveau de la mer, ce qui compte c'est bien l'altitude au dessus d'un lieu, déterminé par l'endroit ou est installé la station.

Tu es à 1700 mètres et si je vois sur ton site l'altitude des nuages à 1720 mètres, je vais en déduire qu'il y a une bonne visibilité, alors que justement il y a certainement un point de rosée proche de la température et qu'il y de ce fait du brouillard.

Avec une information rapportée au niveau de la mer, on devrait pour chaque station, connaître son altitude et la déduire de la valeur indiquée, à mon avis ce n'est pas très pratique.

http://www.boock.ch/meteo/base_nuages.php

A+

[slyworld]

Je suis peut etre influencé par le milieux aéronautique mais parler de plafond nuageux en relatif me parrait etrange.....

Si on prend des exemples de stations en montagne, si une d'elle se trouve a 2500m et que son plaf relatif est de 10m, on peut croire qu'il n'y a pas de conditions météo favorable (au vol par exemple) alors que ca n'est pas le cas et inversement, si on prend une autre station en fond de vallée, celle ci nous donnant 500m par exemple et bien la, on auras l'impression inverse de bonnes conditions alors qu'en réalité non....

Si vous regardez les sites météo indiquant des plafonds nuageux, ils indiquent tous des plafonds absolu....

dans tous les cas, peut etre serait-il judicieux d'avoir le choix entre plafond absolu ou plafond relatif !

[paaubert]

Salut,

C'est vrais que aéronautiquement ça se tient, tu peux corriger cette valeur dans les propriétés des sondes.

nuages.jpg

[slyworld]

merci pour ta reponse mais j'ai déjà essayé ...... ayant une WMR200, la station ne fourni pas directement cette donnée, c'est donc une donnée calculée par graphweather (si j'ai tout bien compris) et donc, meme si je rajoute 1700m dans le champ que tu m'as indiqué, ca n'a aucune influence sur la valeur finale que me donne le logiciel..... :/

une autre idée peut etre ?

[paaubert]

Bon chez moi ça fonctionne, autrement pas d'autre solutions.

nuages2.jpg

[bob13]

Bonjour, slyworld

je ne comprends pas ton raisonnement.

Dans tous les messages meteo (metar, taf) la base des nuages est estimée par l'observateur. Elle détermine l'espace disponible entre le sol et le nuage et en fonction de cela un pilote sait s'il peut voler en VFR. et c'est pourquoi la valeur n'est jamais en fonction du niveau mer.

Dans ton exemple :
exemple : cloud_base me renvoit en ce moment meme l'altitude de 165m ..... ma station est positionné sur le toit de ma maison qui se trouve a ..... 1700m ! et je vous garantie que je ne suis pas dans les nuages

un observateur dirait, j'ai un plafond de 165m comme le fait le logiciel et il enverrait un message de 005 pieds qui correspond à des cu fra ou stratus et non 062 pieds pour des sc (1700+165). Et un pilote dans le premier cas, le vol VFR est impossible dans cette zone et dans le deuxième cas un vol VFR lui est possible .

Ce qui confirme la première remarque de paaubert qui est très juste.



J'ai peut être mal compris ta remarque mais pour un ancien prévi cela me fait dresser les cheveux sur la tête.



A+

[slyworld]

@paaubert : peut être que c'est dû a la version de graphweather, je vois que tu utilise la version 3 alors que j'utilise la version 2, je testerais la 3 a l'occas ! merci en tout les cas de tes réponses

@bob13 : visiblement, tout est une question d'habitude.....on m'as toujours donner des plafonds en mètres AMSL......je trouve ca plus pratique car de cette manière, pour un secteur donné, on sais si on peut passer tel ou tel montagne sans être obligé de demander "le plaf est de 350m OK mais quel est l'altitude de cette station ?" je préfère "le plaf est de 2500m en chartreuse OK, je sais que je peux passer au dessus des lignes de crêtes !".....je pensais que tout le monde fonctionnait comme ca mais je me trompe visiblement remarque, si on prend l'exemple des altitudes, une partie du monde aéronautique fonctionne en pieds et l'autre en mètres......alors les gouts et les couleurs !

a+

[paaubert]

@paaubert : peut être que c'est dû a la version de graphweather, je vois que tu utilise la version 3 alors que j'utilise la version 2, je testerais la 3 a l'occas ! merci en tout les cas de tes réponses

Je ne peux pas dire si c'est la version ou le fait que j'utilise WL, qui lui donne cette valeurs.

A tester donc.

A+

[paaubert]

Je viens de tester avec la V2 et WL, ça ne fonctionne pas, c'est donc bien un problème sur la V2

A+

[bob13]

remarque, si on prend l'exemple des altitudes, une partie du monde aéronautique fonctionne en pieds et l'autre en mètres......alors les gouts et les couleurs !

a+

Bonsoir,

Je n'ai jamais travaillé dans un aérodrome, mes clients étant : pilotes de ligne, de chasse ou de transport. Je connais très mal ou pas les us et coutumes pour les pilotes d'avion de tourisme ou Ulm.

Mais la réglementation internationale (OACI : Annexe 5) toutes les données sont En ft, Hpa, en mètre ou miles nautique pour la visibilité, nœuds Kt pour le vent. Et si on osait sortir de ça !

A+

[MAGNUS]

Bonjour à tous et toutes,
Eh pourquoi ne pas faire fuguer les deux graphiques, l'une par rapport au niveau de la mer et l'autre par rapport à sa localisation ?
Cordialement.

[slyworld]

merci pour ton test paaubert ! la prochaine fois que je met a jour mon minipc, je testerais la version 3 de graphweather !

@bob13: j'avais plus ou moins des idées de ce genre concernant la DGAC et l'OACI mais faisant partie du monde du vol libre, nous avons, certe des bases communes, mais aussi des divergences bien établie : nos altitudes sont en metres (a part quand on apprend les regles de vol a vue...) notre vitesse est en Km/h en horizontale et en m/s en verticale....bref, ca ne m'etonne pas vraiment d'avoir des références différentes de ces instances

[slyworld]

Je viens de finir de mettre en place la version 3 de graphweather et effectivement, la correction altimétrique marche !
j'ai résolu en plus quelques soucis d'incompatibilité avec VNC grace a cette version ! bien content
et effectivement, elle est franchement plus rapide sur mon eeepc asus !

merci encore paaubert !

PS : mon sous-site météo pour les intérressés

http://hiver.belve.fr/Meteo.htm