Space Weather

[marqh]

Add a new report type, with a new schema, to support Space Weather reports

[braeckel]

@marqh Based on the initial implementation it appears that the new Space Weather product may require two new Code Tables in the registry (note that the paths and names are proposed):

http://codes.wmo.int/49-2/SpaceWxPhenomena

• HF_COM_MOD "HF communications (propagation, absorption) - moderate"
• HF_COM_SEV "HF communications (propagation, absorption) - severe"
• SATCOM_MOD "Communications via satellite (propagation, absorption) - moderate"
• SATCOM_SEV "Communications via satellite (propagation, absorption) - severe"
• GNSS_MOD "GNSS-based navigation and surveillance (degradation) - moderate"
• GNSS_SEV "GNSS-based navigation and surveillance (degradation) - severe"
• RADIATION_MOD "Radiation at flight levels (increased exposure) - moderate"
• RADIATION_SEV "Radiation at flight levels (increased exposure) - severe"

http://codes.wmo.int/49-2/SpaceWxLocation

• HNH (high northern hemisphere)
• MNH (middle northern hemisphere)
• EQN (equatorial latitudes northern hemisphere)
• EQS (equatorial latitudes southern hemisphere)
• MSH (middle latitudes southern hemisphere)
• HSH (high latitudes southern hemisphere)
• DAYLIGHT_SIDE

[braeckel]

These proposed locations are in the IWXXM model at the moment, so if we decide on a different location we will need to update the model

[braeckel]

One question that has emerged is how to represent the daylight side/hemisphere of the earth in GML in a way that is unambiguous when visualized/interpreted. One of the challenges is that the subsolar point (the point on earth closest to the sun) changes with both time of year and time of day, and would be different for each forecast group (generally 6 hours apart) of each space weather message.

A few options come to mind:

1. Represent as a polygon. This would be an imperfect, approximated representation of what is essentially circular, and crossings over the north pole and over the anti-meridian are likely to be a challenge for consumers. This fits easily into existing IWXXM constructs, however, and is the most consistent with the other latitude/longitude reporting concepts (such as high north latitudes - HNH)
2. Represent using an Orthographic projection in some way. This may be challenging based on the fact that there are are almost certainly not existing EPSG codes for every subsolar point that should be reported, so placing a circle by center point or other geographic shape oriented on an existing Orthographic EPSG code with the appropriate origin may not be feasible
3. Represent as a circle by center point in EPSG:4326. The point would be the subsolar point with a radius around that point measuring 1/4 of the circumference of the earth. This creates the possibility of errors (of unknown scale as of yet) if the display/consumer software uses different assumptions as to the circumference of the earth than the producing space weather center, and there may be other consumer interpretation issues
4. Report only the subsolar point in EPSG:4326. This leaves more up to consumer/display software to interpret this correctly and we may find that different consumers have slightly different interpretations

At the moment I favor option 4 because it is both accurate, minimal, and relatively straightforward for SWXCs. The question would be how this point is interpreted into a full hemisphere by consumers, or whether more explicit and familiar GIS definitions would be helpful for aviation use.

[blchoy]

I think we only want to represent the bounding circle but not actual hemispherical surface which is quite difficult to represent.

Following the same rational in requiring originators to code areas in bounding polygons rather than "N of ..." in SIGMET (less ambiguity on the user side), we should adopt options 1 or 3 only. My personal preference is 3.

[braeckel]

Space weather will be released as part of Amd 78 but will be applicable Nov 2019.

[braeckel]

@sforeman Based on discussion today it sounds like you may be the right person to get experimental codes in the WMO Codes Registry (see #50 (comment))

[blchoy]

@marqh has kindly include the necessary entries into test.wmocodes.info. While the URLs are resolvable, we still need an RDF file for offline validation. Could @marqh please advise how to do this with the test site?

[blchoy]

The RDFs are now available and incorporated into 3.0.0RC1 for evaluation. At the telecon on 24 Aug 2018, the team had agreed to proceed with approval of the code lists. This issue is hereby closed.