Good morning,
as far as I can see, the USA is the only country where the AIRMET format is used. As AIRMETs are only used for "moderate" phenomena (below SIGMET level), are there any jet operators in the US that use AIRMETs in their flight plans in addition to SIGMETs?
Regards,
|-|ardy
AIRMET are Worldwide Hardy.
Here at the Portuguese MetOffice we produce AIRMET too. FL150 is the higher ( AIRMET and GAMET refer to lower levels, bellow 150 in PT, 100 in other parts of the World ).
Usually AIRMET complement information not provided in a GAMET for specif phenomena. AFAIK used mostly by GA, and operations at the lower FLs as you wrote.
See ICAO Annex 3 Chapter 6 or here:
https://www.icao.int/EURNAT/EUR%20and%20NAT%20Documents/EUR%20Documents/014%20-%20EUR%20SIGMET%20and%20AIRMET%20Guide/EUR%20Doc%2014%20%20(EN)%20-%20Edition%202,%202010%20-%20rev%2029Oct2018.pdf
Thanks. What I actually mean by "format" is the method how the phenomenon location is described in the USA; they don't use the lat/lon system as per the ICAO standard but place-bearing/distance from navaids. They don't start with the keyword "WI" ("within") but with "FROM" or "BOUNDED BY", followed by a sequence of navaid related place-bearing/distance points. I need to develop an extra parser for this, with nav database search and cache functions too. (The parser for the ICAO standards is finished.)
I just don't want to invite future PSX users to paste hundreds of AIRMETs into PSX just because of some moderate turbulence. SIGMETs are OK.
|-|ardy
Hi all,
do PFPX and Simbrief include non-ICAO SIMGETs anyway?
By "non-ICAO" I mean this location format:
... FROM YSC TO 40ENE ALB TO 20SE HNK TO 60WSW HNK TO 30WSW SLT
TO 50W ERI TO 40NNE ERI TO 20SSE YOW TO YSC ...
By "ICAO" I mean this location format:
... WI N4245 W00015 - N4700 W00015 - N4715 E00100 - N4230 E00100 -
N4245 W00015 ...
Regards,
|-|ardy
My current test sources:
https://www.aviationweather.gov/sigmet/data
http://www.flightwork.com/weather/sigmet.html
Hardy,
PFPX snapshot taken from my PFPX which is fed with live real world WX updates from the PFPX WX server about 2 mins ago...
(https://i.imgur.com/nM5y9nYh.png?1)
(https://i.imgur.com/ADp6Bylh.png?2)
Regards
Steve
Thanks, Steve. Well, these are ICAO regions. These SIGMETs are always in ICAO format. It would be interesting to see the USA. The PFPX map probably looks similar to the map at https://skyvector.com
Fortunately, in this moment now, it's the first time since I've started to work on this subject that a SIGMET is being displayed in the USA (near Seattle):
WSUS06 KKCI 180532
SFOO WS 180532
SIGMET OSCAR 1 VALID UNTIL 180932
SIGMET
WA OR AND CSTL WTRS
FROM HQM TO 40SSE SEA TO 20S OED TO 90W OED TO HQM
OCNL SEV TURB BLW 120. DUE TO STG LOW LVL WNDS AND STG UDDFS AND
LLWS. RPTD BY ACFT. CONDS CONTG BYD 0932Z.
I assume, if you were to make a flight plan now across this area, PFPX would include this in the OFP.
Regards,
|-|ardy
These americans really like to break rules... :-/
SIGMET parsing in general is a nightmare :-) Even in ICAO regions there are undocumented "dialects", like using decimal fractions of a degree instead of minutes, etc. (funny effects on Skyvector's maps). Meanwhile I even started to add filters for common typos and non-existent spaces where spaces should be, etc.
Quote from: Hardy Heinlin on Tue, 18 Dec 2018 08:15
Thanks, Steve.
I assume, if you were to make a flight plan now across this area, PFPX would include this in the OFP.
No problem - always happy to assist.
If only it were that simple...unless I am missing something...
Users have to first select the FIRs containing the SIGMETS then paste them to a virtual scratchpad before printing to a separate document from the flightplan, hopefully PFPX will become sufficiently intuitive in time to automate this process.
Ah, users paste them manually into their OFP anyway? OK, no problem. So this stuff is even independent of any flight planner software, and we can solely refer to skyvector.com or aviationweather.gov, for example.
In my tests I just copy the entire global SIGMET text page from one of the international websites and paste the text into a new SIGMET text editor page in PSX, and thus the whole current SIGMET world is injected into PSX. They also appear on the Instructor map. Similar to the new "wind & OAT corridor" text editor, users can edit the SIGMET text blocks and design their own weather scenarios in "SIGMET" language.
It works very well so far. But my parser needs further fine-tuning for all those common typos and "dialects". This stuff is actually a case of Artificial Intelligence algorithms (automatic learning by doing).
|-|ardy
Examples:
(Click on pic to enlarge)
(http://aerowinx.com/assets/pics/psxExtra1003.jpg)
(http://aerowinx.com/assets/pics/psxExtra1004.jpg)
(http://aerowinx.com/assets/pics/psxExtra1005.jpg)
|-|
Hardy,
This looks even more pleasing!
Do the SIGMETS get downloaded by PSX or is this something we need to copy and paste into the box (or of course inject from PSX Dispatch into the relevant variable)?
Ignore me... I just read above. PSX Dispatch already handles the data so I will add a feature into BACARS to populate the relevant variable when the feature becomes available.
Cheers
G
An elegant solution as ever Hardy.
Looks really good.
Does anybody know the update interval of this web site?
https://www.aviationweather.gov/sigmet/intl
I couldn't find any hint. It doesn't always agree with the SIGMETs on Skyvector.com.
Originally I wanted to suggest to manually copy & paste the SIGMET text page over to PSX. But now I'm planning to implement an autodownload option. The SIGMET world data is not so big actually. There are typically just 50 to 90 SIGMETs around the globe. There's always a large complex thunderstorm show in South America. Great stuff :-) And always many small volcanic ash areas at the Pacific coastlines.
|-|ardy
Hardy,
Here is some contact info for that website. I had contacted them a couple years ago about downloading some weather-related data.
Mike Bettwy
Warning Coordination Meteorologist
Aviation Weather Center (NOAA/NWS/NCEP)
7220 NW 101st Terrace
Kansas City, MO 64153
Office: 816-584-7239
Mobile: 410-703-1817 / 913-626-9386
mike.bettwy@noaa.gov
-Mark
Thanks, Mark. ... I'll wait a little; maybe the info is already there somewhere, before I bother him with such a trivial question :-)
|-|ardy
And he's probably furloughed, anyway... our whole professional operation is grinding to a halt at work as the FAA isn't doing anything right now. We are canceling aircraft installations planned during C-checks and so forth. Major schedule headaches.
Hoppie
I will add a checkbox:
[x] When downloading METARs also download SIGMETs
I'm getting the impression some SIGMET writers insert typos intentionally.
Find the error:
WSSN31 ESWI 102216
ESAA SIGMET 7 VALID 102245/110245 ESSA-
ESAA SWEDEN FIR SEV TURB FCST WI N6230 EO1130 - N6230 EO1400 - N6845 EO2130 -
N6915 E02000 - N6800 E01645 - N6230 E01130 SFC/FL070 STNR NC=
Skyvector's parser autocorrected it internally. Some errors are such that Skyvector shows the area incorrectly while my parser can autocorrect it, and with some other errors it's vice versa. One just cannot read the mind of the SIGMET writer. E.g. W1755 (5th digit missing) could mean W17550 or W01755. One could make a distance plausibility check, but this cannot always work either ...
Abuse the typos. If your parser breaks on a SIGMET, that SIGMET becomes volcanic ash. Fun!
And the poor PSX users must suffer? :-)
No, erroneous SIGMETs are just skipped.
But, seriously, is it vodka or what when someone is mixing at random upper case "O" letters with zeros "0" in a sequence of lat/lon points? I mean, one even need to hold the SHIFT key to produce this nonsense!
Now with download system:
(Click on pic to enlarge)
(http://aerowinx.com/assets/pics/psxExtra1006.jpg)
(http://aerowinx.com/assets/pics/psxExtra1007.jpg)
|-|
I feel your pain Hardy...
Mine were written, long ago, using Lex & Yak + Good-old "C" on Vax-VMS, then latter Ultrix... :-)
It's a true PITA... Don't know how our Swedish colleagues work, but sometimes our aviation meteorologists are really in stress, during the whole 12hr shift they do, sometimes alone! It's not that difficult to do typos, I guess...
It's looking Astonishingly Beautiful!!!
I now understand the reason for that typo better: The guys probably always have the Caps Lock on, so no extra shift key press; and the O key is directly under the 0 key :-)
I implemented a filter that converts every O in an assumed lat/lon word to a 0.
A more serious problem is to assure whether an arc "minute" value actually indicates
minutes or decimal fractions of 1.
E.g. W07733 could mean 33 minutes or 0.33 degrees. In almost all cases it's minutes. Almost.
Quote from: Hardy Heinlin on Fri, 11 Jan 2019 00:11
But, seriously, is it vodka or what when someone is mixing at random upper case "O" letters with zeros "0" in a sequence of lat/lon points? I mean, one even need to hold the SHIFT key to produce this nonsense!
It's my wild, wild guess. You know I always first go to stupidity before I fall towards malicious intent, when I see something silly.
I bet this is an OCR job of the stupid kind. The capital O occurrences are next to the letter E. The system just didn't know for sure what to make of the circular shape and errored towards letters.
Why o why OCR is in the loop -- don't ask me.
Quote
I now understand the reason for that typo better: The guys probably always have the Caps Lock on, so no extra shift key press; and the O key is directly under the 0 key :-)
This is a lot more plausible in any case. Still -- I bet they don't even know how much trouble it will cause when doing this.
Hoppie
Quote from: Jeroen Hoppenbrouwers on Sat, 12 Jan 2019 00:10
I bet this is an OCR job of the stupid kind. The capital O occurrences are next to the letter E. The system just didn't know for sure what to make of the circular shape and errored towards letters.
That reminds me of the Xerox scanner problems some years ago; the software used an image compression algorithm which sometimes replaced certain similar characters by wrong reference characters. It was used in scientific works, financial papers etc. Big effects, and nobody noticed it for years. It only happend in the highest compression mode, but this was the default mode that Xerox recommended.
http://www.dkriesel.com/en/blog/2013/0802_xerox-workcentres_are_switching_written_numbers_when_scanning
https://youtu.be/c0O6UXrOZJo?t=484
I checked yesterday, and indeed the zones are hand written in the meteorological telecommunications system by my colleagues. They get the coordinates from the various model outputs, use the mouse to read the locations and then hand type them in the MTS... which is of course, just as with AIRMETs, GAMETs and TAFs prone to errors...
Filters are then used. Mine were written in C long ago, but after the various code changes and since I was already away from that area, the new filters are coded in Fortran 99 :-)
I'll try to check how our filters cope with examples like the one you posted above Hardy.. Maybe you can also start selling MTS filters in Java !!!!! :-)
Your work is progressing amazingly !!! Looking fwd into it.
Here's an example of a manually created, fictitious SIGMET that generates a small thunderstorm area. The area is defined by some lat/lon points, and the fuzzy details within the area are randomized.
(Click on pic to enlarge)
(http://aerowinx.com/assets/pics/psxExtra1008.jpg)
(http://aerowinx.com/assets/pics/psxExtra1009.jpg)
(http://aerowinx.com/assets/pics/psxExtra1010.jpg)
|-|
Gary approves of this :-)
So does Stephen ;)
By the way, when such smaller thunderstorm areas occur in the real world, and Active Sky downloads SIGMETs from the Internet, you can be pretty sure that the thunderstorm locations in PSX (which can download SIGMETs on its own) will be very close to the locations in Active Sky. The randomization of the cells within an area depends on the area size. Some areas are as small as Luxemburg, some as big as France ...
|-|
Unless it's a multi-cell system, it'll always be very random, no matter how small the SIGMET polygon is...
Yet, one of the small scale models we use at IPMA can sometimes forecast the almost exact position of some thunderstorms. The IBM P8 also gets in a true thunderstorm when running it :-)
AS uses the very same sources PSX will use for SIGMET, AIRMET, GAMET, TAF and METAR. It complements it with some large scale forecast models, and, I believe, also with satellite image processing to gt better results regarding cloud coverage and types...
EDIT: One aspect I really like in the way PSX models TS systems is their dynamics... I sometimes seat there, either using "M" to freeze the aircraft in place, or by flying in circles and taking shots of the returns in the ND to observe as the cell changes position and shape with time. ( although I believe using "M" doesn't have the very same effect ? )
Motion freeze just freezes the motion of the aircraft.
CB shapes on the radar also change by radar gain, tilt angle and scan altitude. Most PSX users probably always use the radar's AUTO function and don't notice what differences the tilt and gain can make.
CBs generated by the "local zone" features will move as usual. SIGMET generated CBs will not move. They will only move or disappear by SIGMET updates. PSX ignores the forecast parameters in the SIGMETs.
|-|
Quote from: Hardy Heinlin on Sat, 19 Jan 2019 10:28
Motion freeze just freezes the motion of the aircraft.
CB shapes on the radar also change by radar gain, tilt angle and scan altitude. Most PSX users probably always use the radar's AUTO function and don't notice what differences the tilt and gain can make.
CBs generated by the "local zone" features will move as usual. SIGMET generated CBs will not move. They will only move or disappear by SIGMET updates. PSX ignores the forecast parameters in the SIGMETs.
|-|
Ok, looks acceptable to me ( regarding the SIGMET-induced TS ).
Yes I do play with tilt & gain, depending on weather conditions, and on if I'm climbing or descending...
Nice / easy read here: http://code7700.com/radar_gain.htm
Looks very nice!
Quote from: jcomm on Sat, 19 Jan 2019 09:14
...One aspect I really like in the way PSX models TS systems is their dynamics... I sometimes seat there, either using "M" to freeze the aircraft in place, or by flying in circles ...
...but sometime I hate this dynamics: Quite often, when I approach an airport and there is a likelyhood of TS I have the suspicion, that the PSX dynamics "knows" where I want to go and puts a TS cell exactly such, that is moves right into my approach path. Evil :-[
Then I fly holdings with either inbound or outbound track towards my preferred runway, such that I can monitor the weather cell, waiting to move away from the field and hopefully not moving towards my holding position.
Regards, Holger
Speaking of OCR again ...
Some SIGMETs are even so bizarre that they randomly pick some lat/lon points within a sequence of boundary points, and swap these points within this sequence so that the boundary shape becomes a random zigzag shape.
How can this be? How can this be that an OCR picks single words of a sequence of words and swaps them? How be this can? Be how can this? This how be can?
Even more bizarre: Skyvector displays the published incorrect text, yet displays the boundary shape correctly on the Skyvector map. Be it could, it be could, could it be that there's a human at Skyvector that checks the parsed SIGMET geometry manually from time to time?
|-|ardy
Not really. I found the following statement on the Skyvector forums:
QuoteWe attempt to parse the shape from the Sigmet text. It is very prone to errors. Often, our parser gives up and simply uses the FIR shape as the sigmet shape. If you see a parse error, please bring it to our attention and we'll see if we can make it better.
Maybe this is the secret? 😊
Best regards,
Dirk
I didn't know this quote, but, indeed, I noticed on their maps that they just use the entire FIR if the SIGMET contains pure nonsense.
However, their zigzag corrections refer to the points in the SIGMET texts; in that case they don't draw the FIR. There must be a huge correction algorithm that checks for the most reasonable sequence. It's relatively easy to detect a self-crossing shape. But it's not easy to find out which point is the wrong one, especially if there's no self-crossing at all in the zizag line. Some areas intentionally include angles greater than 90°.
Cheers,
|-|ardy
I'm really wondering why the shapes of the SIGMETs are not simplified per se.
After all, the SIGMETs are based on weather model outputs and they are not very accurate. The GFS model has a resolution of 28 km, for example. In my opinion it would make much more sense to highlight the areas with a simplified (and slightly oversized) rectangular shape.
Around the globe I see very different individual styles of "boundary drawings". Maybe there are different "schools". Some guys often draw just rectangles, some others often draw very fine "Mona Lisas" with many details down to the mile -- partially or entirely along the entire boundary hundreds of miles long. Especially in the Brazil area there are often pretty complex artworks :-) The area between Brazil and West Africa generally displays a great gallery of many large and complex SIGMET areas (mostly thunderstorms).
I don't think that all SIGMETs are based on weather models. Some are inflight reports. And I guess some are ground or radar observations. Some phenomena like dust or ash may be automatically reported by satellite systems.
|-|
Hi Hardy,
Can PSX parse tropical cyclone SIGMETs in the format below? I only ask because SkyVector can't. I suspect it has something to do with the "WI 280NM OF TC CENTRE" element.
WCAU01 ABRF 071910
YBBB SIGMET D02 VALID 071915/080115 YBRFYBBB BRISBANE FIR TC SANDRA PSN S1500 E15600 CB
OBS AT 1800Z WI 280NM OF TC CENTRE TOP FL500 MOV NE
07KT INTSF =
James.
Hi James, no problem parsing "... NM OF TC". It's a standard phrase.
(Click on pic to enlarge)
(http://aerowinx.com/assets/pics/psxExtra1011.jpg)
Regards,
|-|ardy
Outstanding!
That's fantastic ... can't wait to see it in action. 😊
Quote from: Hardy Heinlin on Wed, 23 Jan 2019 02:27
Around the globe I see very different individual styles of "boundary drawings". Maybe there are different "schools". Some guys often draw just rectangles, some others often draw very fine "Mona Lisas" with many details down to the mile -- partially or entirely along the entire boundary hundreds of miles long. Especially in the Brazil area there are often pretty complex artworks :-) The area between Brazil and West Africa generally displays a great gallery of many large and complex SIGMET areas (mostly thunderstorms).
I don't think that all SIGMETs are based on weather models. Some are inflight reports. And I guess some are ground or radar observations. Some phenomena like dust or ash may be automatically reported by satellite systems.
|-|
We use at most 8 points, convex polygons. Our models are WAFCs ( 120km ), ECMWF ( 20 Km ) and AROME can also be used with res down to 2,5 Km. Information is complemented, among other sources, by AIREP.
Here's a nice example of different "drawing styles".
The boundary of SBBS 17 looks extraordinarily detailed. Is this polygon human made or machine made? Look at its "nose tip" to the left: There's an additional tiny little leg inserted to make the nose round. Or look at its northern part: There's a small round bulge consisting of five short legs; they're just some miles apart. When someone paints such details, it's true love ...
(http://aerowinx.com/assets/pics/psxExtra1007.jpg)
|-|
Indeed Hardy - that's "Aviation Weather Art" !
Congratulations for being able to display it so well in the PSX Map !
I guess that just as with tropical cyclones in the example further above in this thread, these shapes are automatically drawn.
And, btw: Today's EDUU creativity :-)
WSDL34 EDZF 241400
EDUU SIGMET 1 VALID 241400/241800 EDZF-
EDUU RHEIN UIR SEV TURB FCST W OF LINE N4948 E00632 - N5029 E00647
FL200/350 MOV E 05KT NC=
(http://www.hoppie.nl/forum/var/EDDN-Sigmet.jpg)
In some cases the rather complex form is also associated with the limits of the FIR / UIR. For instance here in Portugal the Lisbon FIR is delimited over mainland to the East and North by the "complex" geographical frontier with Spain. When a SIGMET starts to the West and South of this lines, the represented resulting SIGMET well have those contours, unless a polygon is designed that intercepts the Spanish FIRs.
The recommendations are well defined, within EUR, by ICAO EUR DOC 014 ( Edition 2, 2010 - rev 29Oct2018 ), with some interesting examples in Appendix G.
The base recommendations is actually that otherwise the polygongs should be defined by no less than 4 points and no more than 7.
PSX has no FIR database.
For "[direction] OF LINE [points]" formats within a FIR, PSX ignores the political FIR borders and sets a polygon whose one side is defined by that published "LINE [points]" and whose other side is defined by "[direction] OF". The distance to the other side is set by a typical average value. This works very well.
When an area is defined by "ENTIRE FIR", PSX uses a rectangle defined by the airport database; e.g. an FIR ID starting with the letters LP will be defined by the westernmost, easternmost, northernmost, and southernmost locations of all airports whose ICAO codes start with LP.
In most cases this agrees very well with the political borders. We're speaking of fuzzy weather areas. Weather doesn't stop at political borders. Even when the borders disagree a little more, the neighbour states will publish a similar SIGMET in their area and so the areas will overlap anyway. Same weather phenomenon, just different governments. And if the neighbours don't publish a SIGMET even though they should, it won't hurt if the simulator's fuzzy weather area goes a little bit into their area as well. It's realistic and plausible. Weather effects ending exactly at political borders are not realistic.
|-|
"Your SIGMET is encroaching on our sovereign airspace - we demand immediate WXEXIT!"
Sorry - couldn't resist :)
Interestingly, a Florida SIGMET is encroaching on European/African airspace.
USA SIGMETs define boundary points by navaids. And this Florida SIGMET includes "MIA".
There are multiple MIA navaids on the planet. The USA SIGMET algorithm in PSX takes the nearest relative to the center of the USA.
The MIA navaid at Miami is not a VORTAC, not a VORDME, not a VOR, not an NDB.
It's a VOT.
VOTs are test VORs at airports. They are not included in the navigational database. So PSX picks the MIA NDB at the Spanish city Melilla at the coastline of Morocco.
Why do they use this TEST VOR of all nice VORs within the Miami terminal area? In flight, one cannot even use these MIA bearing/distance values published in that SIGMET.
Sigh,
|-|ardy
Hardy,
your approach to the SIGMET areas is perfectly adequate and actually agrees with some of the recommendations / examples in the above mentioned ICAO EUR doc 014 :-)
Those americans are really weird .... ( sorry :-) )
Another theory: it is not even a VOT. It's the airport. Of course it should have been KMIA but hey, who cares? It's always "K". I really never had even heard of the existance of MIA VOT. Dolphin, Virginia Key, that's it.
You may want to add a hack: if you don't find a plausible navaid within x miles in the USA, prefix K and scan the airports database. Or, simply always includes the airports.
Hoppie
Quote from: Hardy Heinlin on Fri, 25 Jan 2019 02:10
Weather doesn't stop at political borders.
Climate does, though.
Hoppie
KMIA, I had thought so too. But then I returned to the original idea that the purpose of all this traditional navaid/bearing/distance format is to provide GPS-less radio pilots with useful navaid references. You get no radial and DME signal from KMIA when you are in IFR weather. In VFR you may refer to visual references and the compass to find KMIA ...
If this happens one more time at another airport, I'll add an airport checker.
(I wanted this format to be as universal as possible, so that it can be used outside the USA as well.)
|-|
Do pilots navigate SIGMET areas that precisely? I would guess that they avoid SIGMET areas before taking off by flight planning, and after takeoff, by eyeballing. Not by skirting an imaginary line in the sky between essentially arbitrary points on the globe. Over land you have ATC radar backup, too. And lastly, IFR still means you know pretty well where you are, GPS or not. I vote for the theory that SIGMETs reference "easy points on aeronautical maps" and airports are as easy as navaids.
Hoppie
Well, sometimes Australian SIGMETs use airport ICAO codes to define points. This won't work either because they also use very small airports that are not in the 747 database.
I find the navaid method more useful, even if you plan your route in advance. You can set one of your VOR instruments to a radial that indicates a SIGMET line. SIGMETs can also update during your flight and can be checked on the COM radio.
|-|ardy
If the sigmet was significant I used to put the coordinates in RTE 2 - then you had a pictorial presentation on the ND while flying.
Peter.
Quote from: Hardy Heinlin on Fri, 25 Jan 2019 09:52
KMIA ...
If this happens one more time at another airport, I'll add an airport checker.
OK, today we have something with "TLH" which is not a navaid. But if I search for KTLH I get the point.
I'll add an airport checker :-)
|-|