-
-
Notifications
You must be signed in to change notification settings - Fork 8
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
Cannot parse where visibility is directional #62
Comments
Based on the following, page 25-28, it appears as if the directional visibility will always accompany a primary visibility.
It seems like a visibility with a direction attached will always have a prevailing visibility (without a specific direction). For example
Here's you example, but with the above visibility string, working correctly: It seems like it may be possible (?) to have more than one minimum visibility directions, but I'm not sure. Do you have a specific example of a real METAR with a direction but without a prevailing visibility? |
You may well be right, but it's frustratingly difficult to find a definitive resource. This reference backs up your theory: But this source only refers to "two groups" (not in addition to a prevailing group): And then this source again suggests there is a prevailing visibility followed by a directional visibility: On balance (and based on the "officialness" of the above sources) it does seem that you're correct that a directional visibility should follow a non-directional visibility. Happy to close this if you are. |
Sounds good! Please let me know if you find anything weird like this in a real METAR and I will reopen this. |
According to this page:
It seems that this isn't accounted for by this parser... as per this example it gives the following error:
UnexpectedParseError: container.visibility not instantiated
The text was updated successfully, but these errors were encountered: