wmo-im
Update to spacewx-A7-3 example
The example 'spacewx-A7-3.xml` does not quite accurately convey the same information as the corresponding Space Weather Advisory TAC message. This is probably due to the difficulty of determining, by hand, the boundaries of the latitude bands in daylight for any particular day and time. The current example includes the entire latitude bands from E180 -> W180 being affected by severe HF communication interference which is different from the TAC message.
I will provide an updated spacewx-A7-3.xml that includes the affected area, accounting for the modifier DAYSIDE. It will also update the NIGHTSIDE portion of the document as well.
While updating this example, may I suggest an adjustment to the space weather schema be considered?
Currently, the iwxxm:locationIndicator element is limited to one per iwxxm:SpaceWeatherRegion. I respectfully suggest that it be increased from 1 to 6 so as to include DAYSIDE or NIGHTSIDE and other bands as well in the case of combining them. By allowing up to 6 iwxxm:locationIndicators per iwxxm:SpaceWeatherRegion this would reduce the number of iwxxm:regions in the document when the bands can be joined together. In the case of A7-3, if the affected area was treated as a single polygon (i.e., one iwxxm:location), there would be 4 iwxxm:locationIndicators one for each latitude band affected, and one more for 'DAYLIGHT' to convey that only a portion of the bands are being affected by the hazard in the iwxxm:region. For illustration purposes I have attached it below.
Alternatively, since the region is no longer a simple case of entire bands or one entire side of Earth being affected, it could be considered a polygon rather than a composite of latitude bands with a modifier DAYSIDE. Following the example of spacewx-A7-5.xml, the task team could decide not to include locationIndicator elements for A7-3 as well.
I include Google Earth KMZ files showing the affected area as individual bands and combined. By allowing adjacent latitude bands be combined, as can be done with A7-3 example, the XML file size is reduced by 40%.
Very Respectfully,
mark
As a follow-up to yesterday's comments, the inclusion of more than one iwxxm:locationIndicator element per iwxxm:SpaceWeatherRegion to allow for the modifier 'DAYSIDE' or 'NIGHTSIDE` would be helpful when displaying the forecast graphically/visually in creating a label or annotation to the figure, or in the case of generating a text-only product from the XML. Thus I prefer updating the schema to allow for multiple locationIndicators elements per region, but of course, will accept whatever the task team decides.
Thanks Mark. This has been implemented in IWXXM 2025-2RC2. But instead of replacing the original spacewx-A7-3.xml, I suggest to include both examples to let people know there could be multiple representation.
While implementing the current SWX Advisory, we realised that the schema allows users to construct the same regions in several ways. I am sorry that I didn't realise it sooner.
1. SEV MNH EQN EQS MSH DAYSIDE from spacewx-A7-3.tac
The IWXXM counterpart spacewx-A7-3.xml example is encoded as four band regions (from -180 to 180) and one dayside circle region. It is supposed that a user should somehow know that band regions should be joined as a union, and the final result is an intersection of this union with the DAYSIDE region (represented as a circle).
- Disadvantage: It is unclear from the XSD schema what operation should be used between particular regions.
- Fact: The band region covers the whole band worldwide, from -180 to 180 degrees. The impression is that the band region should be reported as a worldwide band, from -180 to 180 degrees.
- Fact: The DAYSIDE region is represented as a circle by <gml:CircleByCenterPoint/>.
<iwxxm:intensityAndRegion>
<iwxxm:SpaceWeatherIntensityAndRegion gml:id="uuid.34415dca-6fab-45e4-8225-c45960b1e9d2">
<iwxxm:intensity>SEV</iwxxm:intensity>
<iwxxm:region>
<iwxxm:SpaceWeatherRegion gml:id="uuid.0dc02601-d889-4b94-9619-0bddf4f47182">
...
<gml:posList>
30 180
60 180
60 -180
30 -180
30 180
</gml:posList>
...
<iwxxm:locationIndicator xlink:href="http://codes.wmo.int/49-2/SpaceWxLocation/MNH"/>
</iwxxm:SpaceWeatherRegion>
</iwxxm:region>
<iwxxm:region>
<iwxxm:SpaceWeatherRegion gml:id="uuid.03f257e6-63ea-4604-a896-0545c63be45b">
...
<gml:posList>
00 180
30 180
30 -180
00 -180
00 180
</gml:posList>
...
<iwxxm:locationIndicator xlink:href="http://codes.wmo.int/49-2/SpaceWxLocation/EQN"/>
</iwxxm:SpaceWeatherRegion>
</iwxxm:region>
<iwxxm:region>
<iwxxm:SpaceWeatherRegion gml:id="uuid.bf8c0ce9-0e3c-4926-9ada-404c7a377844">
...
<gml:posList>
-30 180
00 180
00 -180
-30 -180
-30 180
</gml:posList>
...
<iwxxm:locationIndicator xlink:href="http://codes.wmo.int/49-2/SpaceWxLocation/EQS"/>
</iwxxm:SpaceWeatherRegion>
</iwxxm:region>
<iwxxm:region>
<iwxxm:SpaceWeatherRegion gml:id="uuid.0cfde53e-07ae-41dd-ac1a-9f0a53789d0a">
...
<gml:posList>
-60 180
-30 180
-30 -180
-60 -180
-60 180
</gml:posList>
...
<iwxxm:locationIndicator xlink:href="http://codes.wmo.int/49-2/SpaceWxLocation/MSH"/>
</iwxxm:SpaceWeatherRegion>
</iwxxm:region>
<iwxxm:region>
<iwxxm:SpaceWeatherRegion gml:id="uuid.0a7f155f-e952-4747-a318-877b46187186">
...
<gml:CircleByCenterPoint numArc="1">
<gml:pos>-16.71 70.94</gml:pos>
<gml:radius uom="km">10100</gml:radius>
</gml:CircleByCenterPoint>
...
<iwxxm:locationIndicator xlink:href="http://codes.wmo.int/49-2/SpaceWxLocation/DAYSIDE"/>
</iwxxm:SpaceWeatherRegion>
</iwxxm:region>
</iwxxm:SpaceWeatherIntensityAndRegion>
</iwxxm:intensityAndRegion>
2. SEV MNH EQN W080-E080
Should this case be encoded as two or as three regions? If we follow the SEV MNH EQN EQS MSH DAYSIDE encoding, the band regions should be reported as a worldwide band, and then we need a third region for W080-E080. Or one can restrict directly band regions as
<gml:posList>
-60 080
-30 080
-30 -080
-60 -080
-60 080
</gml:posList>
So, only two regions can express the same situation.
- Fact: It is not clear how a user should encode this use case.
- Disadvantage: Even though we provide an example for it, there is still a possibility to encode it in several ways, and all of them pass the validation. That increases the requirements on decoders side.
3. SEV HNH HSH W180-E180 from spacewx-A7-4.tac
In this case, two discontinuous regions over the southern and northern poles are reported.
<iwxxm:intensityAndRegion>
<iwxxm:SpaceWeatherIntensityAndRegion gml:id="uuid.c264db5c-3f0b-4444-ab5e-71f48a514644">
<iwxxm:intensity>MOD</iwxxm:intensity>
<iwxxm:region>
<iwxxm:SpaceWeatherRegion gml:id="uuid.e7de7c50-1fde-41b7-995d-a28bdb61e446">
...
<gml:posList>
60 180
90 180
90 -180
60 -180
60 180
</gml:posList>
...
<iwxxm:locationIndicator xlink:href="http://codes.wmo.int/49-2/SpaceWxLocation/HNH"/>
</iwxxm:SpaceWeatherRegion>
</iwxxm:region>
</iwxxm:SpaceWeatherIntensityAndRegion>
</iwxxm:intensityAndRegion>
<iwxxm:intensityAndRegion>
<iwxxm:SpaceWeatherIntensityAndRegion gml:id="uuid.00f9026a-845a-4472-acee-9ec5d7ba6839">
<iwxxm:intensity>MOD</iwxxm:intensity>
<iwxxm:region>
<iwxxm:SpaceWeatherRegion gml:id="uuid.1966a889-fedc-4eb8-9066-578492617298">
...
<gml:posList>
-60 180
-60 -180
-90 -180
-90 180
-60 180
</gml:posList>
...
<iwxxm:locationIndicator xlink:href="http://codes.wmo.int/49-2/SpaceWxLocation/HSH"/>
</iwxxm:SpaceWeatherRegion>
</iwxxm:region>
</iwxxm:SpaceWeatherIntensityAndRegion>
</iwxxm:intensityAndRegion>
- Fact: In this case, it is basically the third way, how the SWX location can be expressed. In other words, one TAC expression is split into two <iwxxm:intensityAndRegion/> elements.
Mark's suggestion to report the joined regions has several advantages
- The consumer will always expect a polygonal area. So the requirement for visualisation is significantly decreased.
- If DAYSIDE and NIGHSIDE (without any other band) are also reported by a polygonal approximation of a circle, then it is aligned with the 1. bullet. Even end users will not need to solve/compute the real affected area. Of course, it still must be calculated on the SWX centres, but there are a few of them compared to the number of consumers. In addition, the replacement of <gml:CircleByCenterPoint/> by the polygonal approximation is a more correct way to represent a circle on the Earth ellipsoid in GML, because <gml:CircleByCenterPoint/> represents a circle in the underlying CRS, not on the geoid.
- If we update the schema spaceWxAdvisory.xsd to allow only one <region/> element in <intensityAndRegionintensityAndRegion/> element and allow to multiply the <location/> in the <SpaceWeatherRegion/>, it will also make the
SEV HNH HSH W180-E180XML expression closer to the TAC. It allows to encode it by one <iwxxm:SpaceWeatherIntensityAndRegion/> with two <location/> elements. So it also aligned the third use case. It will still be possible to report several <intensityAndRegionintensityAndRegion/> by users, even if it is unnecessary, but it will reduce the number of ways the report may be created. That reduces the requirement for encoders and decoders. Here is the proposal spaceWxAdvisory.zip.
We should add guidance to the XSD definition that the number of <intensityAndRegionintensityAndRegion/> should always be a minimum. Also, the explanation in TAC-to-XML-Guidance.txt would be helpful.
The next issue we realised is that we should define how to compute the polygonal approximation of the DAYSIDE and NIGHSIDE. What sunrise/sunset should be taken into account?
| Type | Angle |
|---|---|
| Ideal | dawn is defined as the centre of the sun 0° below the horizon |
| Civil | dawn is defined as the centre of the sun 6° below the horizon |
| Nautical | dawn is defined as the centre of the sun 12° below the horizon |
| Astronomic | dawn is defined as the centre of the sun 18° below the horizon |
We should add guidance to the XSD schema and update the TAC-to-XML-Guidance.txt to determine which sunset/sunrise should be used.
I also removed MOD_OR_SEV (see the proposal above) because it seems that this option is not mentioned in the amendment.
https://github.com/wmo-im/iwxxm/wiki/TT-AvData-Discussion-2025-Jun-4 notes: Jan tried to find ways to minimize the options for regions for DAYSIDE and NIGHTSIDE Choy agrees with the approach and can implement it soon in the schemas to be discussed with space weather data producers
@blchoy and @amilan17 if you wish to contact NOAA Space Weather Prediction Center, I or Paul H can give you that information. My most recent conversation with them in late April indicated that they will likely not be able to implement Amendment 82 changes in November due to ongoing resource constraints.
I stole the following picture from a Working Paper of ICAO WG-MOG/19 in 2023 which mentioned an initiative called "Space Weather Advisory Map Service for Aviation". Don't know its current status, but more importantly it shows how the locations interact with each other:
So our assumption that separated areas union while overlapping areas intersect looks right, but there is still uncertainty whether the order of the bands/areas in the list matters. In any case it should not be a concern since the producer knows exactly what the final area should look like. In that case, following all the hard work Mark and Jan have made, we will modify the schemas in the following ways:
- Reduce the multiplicity of iwxxm:region to [1..1]
- Increase the multiplicity of iwxxm:locationIndicator from [0..6] to [1..6] (the change from 0 to 1 is to make this element mandatory. See Issue #350.
- Make a note in TAC-to-XML that one should put into iwxxm:location the consolidated affected area (as in the Advisory Map web site) and the associated bands/areas mentioned in TAC in iwxxm:locationIndicator
Just want to also show possible evolvement of the Space Weather Advisory. The following is extracted from a working paper discussed at ICAO WG-MOG/28 in 2024. Please note that what is being shown is subject to final decision of the respective groups:
https://github.com/wmo-im/iwxxm/wiki/TT-AvData-Discussion-2025-Jun-13 notes: Jan and Choy discussed pros and cons of the options based on recent schema changes
During the implementation we encountered an interesting fact. Here is an example of MNH EQN MSH DAYSIDE
And this is how it would be currently encoded in 2025-2RC2:
<iwxxm:intensityAndRegion>
<iwxxm:SpaceWeatherIntensityAndRegion gml:id="uuid.c264db5c-3f0b-4444-ab5e-71f48a514644">
<iwxxm:intensity>MOD</iwxxm:intensity>
<iwxxm:region>
<iwxxm:SpaceWeatherRegion gml:id="uuid.e7de7c50-1fde-41b7-995d-a28bdb61e446">
<iwxxm:location>
<aixm:AirspaceVolume gml:id="uuid.7138f8d1-9854-46cb-a1b1-9d96c5cee46f">
<aixm:horizontalProjection>
<aixm:Surface gml:id="uuid.3b00652b-4bed-4655-959c-1c9efd431cac" srsDimension="2" axisLabels="Lat Long" srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
<gml:patches>
<gml:PolygonPatch>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
0 -176.954 3.97569e-16 3.04075 3.09399 1.97352 8.76264 -0.00419423 14.4207 -2.04332 20.0603 -4.18889 25.6721 -6.49456 31.2441 -9.02791 36.7602 -11.8782 42.1977 -15.1681 47.5237 -19.0721 52.6874 -23.8453 57.6089 -29.8664 60 -33.9802 60 -139.96 57.173 -144.661 52.225 -150.548 47.0437 -155.228 41.7058 -159.067 36.2599 -162.311 30.7379 -165.128 25.1617 -167.637 19.5469 -169.925 13.9053 -172.059 8.24596 -174.091 2.5767 -176.065 0 -176.954
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:PolygonPatch>
<gml:PolygonPatch>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
-30 -179.999 -60 -179.999 -60 40.0275 -57.176 35.3322 -52.2277 29.4453 -47.0461 24.7653 -41.708 20.9268 -36.2619 17.6836 -30.7398 14.867 -30 14.5341 -30 -179.999
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:PolygonPatch>
<gml:PolygonPatch>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
-30 171.544 -31.246 170.977 -36.7622 168.127 -42.1999 164.838 -47.5261 160.934 -52.6901 156.162 -57.6119 150.141 -60 146.033 -60 180 -30 180 -30 171.544
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:PolygonPatch>
</gml:patches>
</aixm:Surface>
</aixm:horizontalProjection>
</aixm:AirspaceVolume>
</iwxxm:location>
<iwxxm:locationIndicator xlink:href="http://codes.wmo.int/49-2/SpaceWxLocation/MNH"/>
<iwxxm:locationIndicator xlink:href="http://codes.wmo.int/49-2/SpaceWxLocation/EQN"/>
<iwxxm:locationIndicator xlink:href="http://codes.wmo.int/49-2/SpaceWxLocation/MSH"/>
<iwxxm:locationIndicator xlink:href="http://codes.wmo.int/49-2/SpaceWxLocation/DAYSIDE"/>
</iwxxm:SpaceWeatherRegion>
</iwxxm:region>
</iwxxm:SpaceWeatherIntensityAndRegion>
</iwxxm:intensityAndRegion>
Geometry information is provided twice (once as Polygon Patches, once as location indicators). Now there is question which one should be taken as a source of truth in case there is a conflict (polygons do not represent what location indicators are saying). Another question is how to correctly pair polygons to location indicators. I think this should not be task for decoding and visualization, because that would only slow down the entire process. Much better would be if this information would be incorporated in the xml itself. Best possible option that comes to my mind is to make it like this
<iwxxm:intensityAndRegion>
<iwxxm:SpaceWeatherIntensityAndRegion gml:id="uuid.c264db5c-3f0b-4444-ab5e-71f48a514644">
<iwxxm:intensity>MOD</iwxxm:intensity>
<iwxxm:region>
<iwxxm:SpaceWeatherRegion gml:id="uuid.e7de7c50-1fde-41b7-995d-a28bdb61e446">
<iwxxm:location>
<aixm:AirspaceVolume gml:id="uuid.7138f8d1-9854-46cb-a1b1-9d96c5cee46f">
<aixm:horizontalProjection>
<aixm:Surface gml:id="uuid.3b00652b-4bed-4655-959c-1c9efd431cac" srsDimension="2" axisLabels="Lat Long" srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
<gml:patches>
<gml:PolygonPatch>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
0 -176.954 3.97569e-16 3.04075 3.09399 1.97352 8.76264 -0.00419423 14.4207 -2.04332 20.0603 -4.18889 25.6721 -6.49456 31.2441 -9.02791 36.7602 -11.8782 42.1977 -15.1681 47.5237 -19.0721 52.6874 -23.8453 57.6089 -29.8664 60 -33.9802 60 -139.96 57.173 -144.661 52.225 -150.548 47.0437 -155.228 41.7058 -159.067 36.2599 -162.311 30.7379 -165.128 25.1617 -167.637 19.5469 -169.925 13.9053 -172.059 8.24596 -174.091 2.5767 -176.065 0 -176.954
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:PolygonPatch>
</gml:patches>
</aixm:Surface>
</aixm:horizontalProjection>
</aixm:AirspaceVolume>
</iwxxm:location>
<iwxxm:locationIndicator xlink:href="http://codes.wmo.int/49-2/SpaceWxLocation/MNH"/>
<iwxxm:locationIndicator xlink:href="http://codes.wmo.int/49-2/SpaceWxLocation/EQN"/>
<iwxxm:locationIndicator xlink:href="http://codes.wmo.int/49-2/SpaceWxLocation/DAYSIDE"/>
</iwxxm:SpaceWeatherRegion>
</iwxxm:region>
<iwxxm:region>
<iwxxm:SpaceWeatherRegion gml:id="uuid.e7de7c50-1fde-41b7-995d-a28bdb61e446">
<iwxxm:location>
<aixm:AirspaceVolume gml:id="uuid.7138f8d1-9854-46cb-a1b1-9d96c5cee46f">
<aixm:horizontalProjection>
<aixm:Surface gml:id="uuid.3b00652b-4bed-4655-959c-1c9efd431cac" srsDimension="2" axisLabels="Lat Long" srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
<gml:patches>
<gml:PolygonPatch>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
-30 -179.999 -60 -179.999 -60 40.0275 -57.176 35.3322 -52.2277 29.4453 -47.0461 24.7653 -41.708 20.9268 -36.2619 17.6836 -30.7398 14.867 -30 14.5341 -30 -179.999
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:PolygonPatch>
<gml:PolygonPatch>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
-30 171.544 -31.246 170.977 -36.7622 168.127 -42.1999 164.838 -47.5261 160.934 -52.6901 156.162 -57.6119 150.141 -60 146.033 -60 180 -30 180 -30 171.544
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:PolygonPatch>
</gml:patches>
</aixm:Surface>
</aixm:horizontalProjection>
</aixm:AirspaceVolume>
</iwxxm:location>
<iwxxm:locationIndicator xlink:href="http://codes.wmo.int/49-2/SpaceWxLocation/MSH"/>
<iwxxm:locationIndicator xlink:href="http://codes.wmo.int/49-2/SpaceWxLocation/DAYSIDE"/>
</iwxxm:SpaceWeatherRegion>
</iwxxm:region>
</iwxxm:SpaceWeatherIntensityAndRegion>
</iwxxm:intensityAndRegion>
This way iwxxm:region contains only those patches that correspond to the location indicators reported in that iwxxm:region. However, this is currently not supported by the schema. There would have to be maxOccurs="unbounded" for iwxxm:region inside SpaceWeatherIntensityAndRegionType. Another option would be to put the entire SpaceWeatherIntensityAndRegion twice (even for the same intensity, which is currently supported by the schema). That would look like this
<iwxxm:intensityAndRegion>
<iwxxm:SpaceWeatherIntensityAndRegion gml:id="uuid.c264db5c-3f0b-4444-ab5e-71f48a514644">
<iwxxm:intensity>MOD</iwxxm:intensity>
<iwxxm:region>
<iwxxm:SpaceWeatherRegion gml:id="uuid.e7de7c50-1fde-41b7-995d-a28bdb61e446">
<iwxxm:location>
<aixm:AirspaceVolume gml:id="uuid.7138f8d1-9854-46cb-a1b1-9d96c5cee46f">
<aixm:horizontalProjection>
<aixm:Surface gml:id="uuid.3b00652b-4bed-4655-959c-1c9efd431cac" srsDimension="2" axisLabels="Lat Long" srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
<gml:patches>
<gml:PolygonPatch>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
0 -176.954 3.97569e-16 3.04075 3.09399 1.97352 8.76264 -0.00419423 14.4207 -2.04332 20.0603 -4.18889 25.6721 -6.49456 31.2441 -9.02791 36.7602 -11.8782 42.1977 -15.1681 47.5237 -19.0721 52.6874 -23.8453 57.6089 -29.8664 60 -33.9802 60 -139.96 57.173 -144.661 52.225 -150.548 47.0437 -155.228 41.7058 -159.067 36.2599 -162.311 30.7379 -165.128 25.1617 -167.637 19.5469 -169.925 13.9053 -172.059 8.24596 -174.091 2.5767 -176.065 0 -176.954
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:PolygonPatch>
</gml:patches>
</aixm:Surface>
</aixm:horizontalProjection>
</aixm:AirspaceVolume>
</iwxxm:location>
<iwxxm:locationIndicator xlink:href="http://codes.wmo.int/49-2/SpaceWxLocation/MNH"/>
<iwxxm:locationIndicator xlink:href="http://codes.wmo.int/49-2/SpaceWxLocation/EQN"/>
<iwxxm:locationIndicator xlink:href="http://codes.wmo.int/49-2/SpaceWxLocation/DAYSIDE"/>
</iwxxm:SpaceWeatherRegion>
</iwxxm:region>
</iwxxm:SpaceWeatherIntensityAndRegion>
<iwxxm:SpaceWeatherIntensityAndRegion gml:id="uuid.c264db5c-3f0b-4444-ab5e-71f48a514645">
<iwxxm:intensity>MOD</iwxxm:intensity>
<iwxxm:region>
<iwxxm:SpaceWeatherRegion gml:id="uuid.e7de7c50-1fde-41b7-995d-a28bdb61e446">
<iwxxm:location>
<aixm:AirspaceVolume gml:id="uuid.7138f8d1-9854-46cb-a1b1-9d96c5cee46f">
<aixm:horizontalProjection>
<aixm:Surface gml:id="uuid.3b00652b-4bed-4655-959c-1c9efd431cac" srsDimension="2" axisLabels="Lat Long" srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
<gml:patches>
<gml:PolygonPatch>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
-30 -179.999 -60 -179.999 -60 40.0275 -57.176 35.3322 -52.2277 29.4453 -47.0461 24.7653 -41.708 20.9268 -36.2619 17.6836 -30.7398 14.867 -30 14.5341 -30 -179.999
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:PolygonPatch>
<gml:PolygonPatch>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
-30 171.544 -31.246 170.977 -36.7622 168.127 -42.1999 164.838 -47.5261 160.934 -52.6901 156.162 -57.6119 150.141 -60 146.033 -60 180 -30 180 -30 171.544
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:PolygonPatch>
</gml:patches>
</aixm:Surface>
</aixm:horizontalProjection>
</aixm:AirspaceVolume>
</iwxxm:location>
<iwxxm:locationIndicator xlink:href="http://codes.wmo.int/49-2/SpaceWxLocation/MSH"/>
<iwxxm:locationIndicator xlink:href="http://codes.wmo.int/49-2/SpaceWxLocation/DAYSIDE"/>
</iwxxm:SpaceWeatherRegion>
</iwxxm:region>
</iwxxm:SpaceWeatherIntensityAndRegion>
</iwxxm:intensityAndRegion>
In both cases it is obvious which polygons correspond to which location indicators.
@ltomovic-ibl: If you check our previous implementation since 2021-2 (see https://schemas.wmo.int/iwxxm/2021-2/examples/) each indicator has its own polygon and there is no ambiguity on their relationships. We now learn that the target coverage is the interception of the indicators (but I suspect that in some cases union will be made). @jkorosi suggested and the team agreed to help client software render by asking the producers to give directly the target coverage polygons and leave the indicators as just labels (i.e. without the need to show their respective polygons). This is because even if we allow the message to carry additional information on how these indicators interact with each other it is still not feasible for the client software to do intersection and/or union on the fly (imagine your application is on an iPad).
I think the most important thing to resolve in this issue is spacewx-A7-4.xml where its corresponding TAC message is:
SWX ADVISORY
DTG: 20201108/0100Z
SWXC: DONLON
SWX EFFECT: GNSS
ADVISORY NR: 2020/2
NR RPLC: 2020/1
OBS SWX: 08/0100Z MOD HNH HSH W180-E180
FCST SWX +6 HR: 08/0700Z MOD HNH HSH W180-E180
FCST SWX +12 HR: 08/1300Z NO SWX EXP
FCST SWX +18 HR: 08/1900Z NO SWX EXP
FCST SWX +24 HR: 09/0100Z NO SWX EXP
RMK: SWX EVENT INPR POSSIBLY IMPACTING GNSS PER. AREA OF
IMPACT MOVES WITH EARTH'S ROTATION, STAYING
STRONGER ON NIGHTSIDE. EXP TO SUBSIDE IN THE FCST
PERIOD. SEE WWW.SPACEWEATHERPROVIDER.WEB
NXT ADVISORY: WILL BE ISSUED BY 20201108/0700Z
Our schema only allows the representation of HNH and HSH but not W180-E180 since iwxxm:locationIndicator is of codelist type:
<iwxxm:locationIndicator xlink:href="http://codes.wmo.int/49-2/SpaceWxLocation/HNH"/>
<iwxxm:locationIndicator xlink:href="http://codes.wmo.int/49-2/SpaceWxLocation/HSH"/>
Personally I think this is undesirable as the IWXXM version cannot fully recreate its TAC counterpart in terms of indicators. What do you think @jkorosi and @amilan17?
To my understanding, a space weather advisory is a type of meteorological report, and TAC and IWXXM are simply two formats in which this report can be disseminated. However, the structure of these two formats for space weather advisories is currently not aligned. There are differences—specifically, there are aspects of the TAC format that cannot be represented in IWXXM. For example, we are able to visualize TAC with labels for the corresponding polygons, whereas this is not possible with IWXXM unless we provide a mapping from polygons to location indicators (so that the client side does not have to compute those intersections and unions). This seems somewhat backwards, considering IWXXM is supposed to represent the bright new future, while TAC is intended to be phased out within the next few years.
What I suggested was not to provide a separate polygon for every single location indicator, but to specify which location indicators were used to compute each polygon. This can be clearly seen in the example I provided above, where one polygon is grouped with three location indicators and the other with two. No computation on the client side is needed.
Regarding the W180–E180 coordinate restriction, yes, it is unfortunate that this can be represented in TAC (the old format) but not in IWXXM (the new shiny format). Honestly, I don't know how to solve this. It would be nice if a location indicator could be not just a code list entry, but could also include two coordinates as a restriction. However, that would require a change to the schema.
What I suggested was ... to specify which location indicators were used to compute each polygon.
Is that important? The producer of the message tells you the target polygon so that you do not need to do your own calculation which you have to with TAC. Do they need to justify how they determine the target polygon with the location indicators?
During the previous meeting I mentioned that the expert team involved in the development of SWA has an intention to go away with location indicators. I do think there will be further refinements to SWA, and we should be proactive in telling them what they should or should not do with XML.
Do they need to justify how they determine the target polygon with the location indicators?
In order to be able to visualize the IWXXM version in the same way the TAC one can be visualized, then yes. In case everyone is OK with IWXXM being visualized without the information about which polygon represents which location indicators, then no, it is not needed.
@ltomovic-ibl thanks for pointing out. There are different views regarding what IWXXM should be. Some folks said it should only carry data and nothing else. Others would like it to also contain some kind of rendering hints/directives (such as WAFS Signifcant Weather Forecast). To achieve the latter we will need to have direct conversations with the producers and potential consumers to understand their anticipated use cases in designing the IWXXM package (and we did that for newer IWXXM packages like WAFS SigWx FC, VONA and QVA). SWA is one of what we regarded as legacy messages which all we have during the design of the respective IWXXM packages were the TAC templates. This team should not go too far in assuming how information will be consumed without going through the process to consult various parties (ICAO, States, etc.), and the possible representation of consolidated polygon from location indicator is the furthest I can accept.
Because of time we need to conclude. I would suggest:
- Make sure the schema allows both representations, the current one (showing a location indicator and its corresponding polygon) and the new one (showing consolidated polygon and a list of contributing location indicators).
- Adjust the examples to continue showing existing representation, viz one location indicator and its corresponding polygon.
- Add additional examples to show possible alternative representation, viz a consolidated polygon and a list of contributing location indicators.
If I hear no objection to this arrangement, I will commit related changes this Friday (4 Jul 2025). Otherwise we will need to call for an urgent meeting to resolve.
I encountered another potential discrepancy:
This in TAC
NXT ADVISORY: 20201108/0700Z
I guess could be represented like this in IWXXM
<iwxxm:nextAdvisoryTime>
<gml:TimeInstant gml:id="uuid.ff02e4b5-e54c-4ec3-b34c-842229274727">
<gml:timePosition>2020-11-08T07:00:00Z</gml:timePosition>
</gml:TimeInstant>
</iwxxm:nextAdvisoryTime>
and this in TAC
NXT ADVISORY: WILL BE ISSUED BY 20201108/0700Z
should be represented like this?
<iwxxm:nextAdvisoryTime>
<gml:TimeInstant gml:id="uuid.ff02e4b5-e54c-4ec3-b34c-842229274727">
<gml:timePosition indeterminatePosition="before">2020-11-08T07:00:00Z</gml:timePosition>
</gml:TimeInstant>
</iwxxm:nextAdvisoryTime>
Documentation in the schema says this
Use attribute indeterminatePosition to element timePosition to indicate if the actual temporal position is before or after the specified value.
However, A7-3 TAC example uses WILL BE ISSUED BY, however, IWXXM does not specify indeterminatePosition attribute. Either I do not understand something, or this attribute should be specified.
You are right. "By" means "at or before". However, gml:timePosition attribute indeterminatePosition can only be used to specify either at or before or after the time position (from ISO 19108):
One can use an open end gml:timePeriod to accurately represent the concept "at or before", but for next advisory time it would be an overkill. I would suggest we use indeterminatePosition="before" only when we have NXT ADVISORY: WILL BE ISSUED BEFORE XXXXXX.
Personally, I see no difference in giving additional description "before", "at or before" or "at" to the time position, as practically a consumer will most likely check for the next advisory "after" the time position, taking into account the message passing, processing and rendering times?
I would suggest we use indeterminatePosition="before" only when we have NXT ADVISORY: WILL BE ISSUED BEFORE XXXXXX.
I guess you meant WILL BE ISSUED BY instead of WILL BE ISSUED BEFORE.
Yes, I agree.
I mean, in TAC, there are two ways (exact datetime or WILL BE ISSUED BY XXXXXX) and for technical reasons we need two ways in IWXXM. I fully agree that we can use "before" to represent WILL BE ISSUED BY XXXXXX.
@blchoy has this work concluded and included in the FT2025-2 branches? If so, can we delete this branch: https://github.com/wmo-im/iwxxm/tree/issue/351 ?