Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Metars with missing cloud info #13

Closed
gpdawson opened this issue Feb 14, 2016 · 6 comments
Closed

Metars with missing cloud info #13

gpdawson opened this issue Feb 14, 2016 · 6 comments

Comments

@gpdawson
Copy link

PAWI 140753Z AUTO 08034G41KT 1/4SM SN FZFG M18/M21 A2951 RMK PK WND 08041/0752 SLP995 P0000 T11831206 TSNO $ VIA AUTODIAL

This metar generates this exception: Bad format for clouds information, on chunk "M18/M21 A2951 RMK PK WND 08041/0752 SLP995 P0000 T11831206 TSNO $ VIA AUTODIAL"

Also, even in non-strict mode, it then fails to parse temperature information, presumably because parser has already jumped to next chunk after not finding cloud info when expected.

According to the specification here http://weatherfaqs.org.uk/book/export/html/197 the cloud info is "optional", although it also says "When fog or heavy snow is occurring, and it is not possible to determine cloud structure, then these groups are replaced by VVhhh or VV///".

I note that there are typically many metar reports (many thousand daily) which do not contain cloud info, mainly from AUTO stations.

So my question is, should missing cloud info be considered an error by this parser, and is there a better way of dealing with this particular case in order to ensure that temperature data is correctly parsed despite missing cloud info?

@inouire
Copy link
Contributor

inouire commented Mar 11, 2016

Hello Graham, thank you for the detailed feedback.
The OACI specification makes it clear that the cloud part is mandatory, so I'll work on a way to make it work, but in non-strict mode only.
What do you think ?

@gpdawson
Copy link
Author

My own interest is in obtaining as much weather information as possible, so I only use non-strict mode, and would be very happy for non-strict mode to be as forgiving as possible. However I do realise that you can only go so far with how lenient you can be before you increase the chance of extracting incorrect data rather than failing to extract any, so only go as far as you think is reasonable.

@inouire
Copy link
Contributor

inouire commented Mar 18, 2016

Hi Graham, I've got some good news !

I've figured out something that gives some pretty good results without being too hazardous on decoding. It is available in v0.7. Be careful that the demo website might not be up-to-date, try it locally instead.

Can you try it and give me a feedback ?

If you're interested, you can have a look at the principle detailed in the README https://github.com/SagemCassiopee/php-metar-decoder#about-parsing-errors-again

@jpjoux
Copy link
Contributor

jpjoux commented Mar 21, 2016

Dear all, just to inform you, the web site is updated automatically 3 times per day. (~ 8:00, 12:00 & 23:00 Paris time)

@gpdawson
Copy link
Author

So far the new non-strict parsing is looking very good. Great job.

@inouire
Copy link
Contributor

inouire commented Mar 21, 2016

Great, I'll close the issue now. Thank you for helping making this library better.

@inouire inouire closed this as completed Mar 21, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants