Initial version of space weather schemas and examples

[braeckel]

No description provided.

[blchoy]

I have several observations:

1. iwxxm:phenomena - Interestingly we have iwxxm:phenomenon (singular) in sigmet.xsd! By the way, the corresponding item in the Annex 3 template refers to "effect of space weather phenomena" instead so we may want to consider renaming it to iwxxm:effectOfPhenomena (still singular) or <iwxxm:phenomenon><effect xlink...></iwxxm:phenomenon> or otherwise?

2. iwxxm:analysis - The use of <iwxxm:SpaceWeatherAnalysis ... timeIndicator="OBSERVATION"> is a clever way to generalise the OBS/FCST block and subsequent FCST blocks and this could also be used in SIGMET, TC/VA advisories and all other reports with this kind of representation. This, however, relies on strict adherence to the sequencing of iwxxm:analysis in the order T+0/T+t0 (OBS/FCST), T+t1 (FCST), T+t2 (FCST), ... and T+0/T+t0 shall always exist. I think this is valid for MET phenomena but we may want to describe clearly in the feature note.

3. iwxxm:nextAdvisoryEarliestTime and iwxxm:nextAdvisoryLatestTime - May be a choice of gml:TimeInstant and gml:TimePeriod provides better options for "next advisory time"?

[braeckel]

@blchoy - thanks for the review.

1. Good catch. The iwxxm:phenomena vs iwxxm:phenomenon difference is due to the fact that AIR/SIGMETs can only report a single phenomenon whereas SpaceWx can report multiple. However, these elements are put in the reports individually (no matter the number, 1 or 7) and I think iwxxm:phenomenon is correct in all cases. I will change all cases to be "iwxxm:phenomenon"
2. If I understand your comment fully, this would look (roughly) like the following: "analysis elements should be reported in order, starting from the initial observed or forecast analysis (T+0), then continuing through all forecast analyses (T+1 through T+N)". My English is a bit lacking today, but assuming I understand your suggestion and you think this is roughly correct I will put in a refined version of this as a note on the "analysis" association. I am avoiding referring to specific forecast times as this is not an unlikely thing to be changed in the future
3. Are you suggesting that we combine iwxxm:nextAdvisoryEarliestTime and iwxxm:nextAdvisoryLatestTime into a single nextAdvisoryTime? If so, VAA and TCA should also be revised to be consistent since this was blatantly stolen from VAA ;)

[braeckel]

Note that the current build failures are due to the fact that the proposed WMO Codes List entries don't exist yet. @marqh are you able to look at this? The proposed code registries are described at #50 (comment), we cannot close this issue until these entries are decided (although it could take longer for them to be added to the live instance)

[blchoy]

With regard to your suggestions:

2. Yes that's right.

3. I am afraid yes. I tend to describe a period instead of separately a start time and/or an end time. Are you thinking of some programing benefits to have the period described in two separately elements?

[braeckel]

Going back to the Annex descriptions, SWAs have the following options for "expected time of issuance of next advisory":

1. 20040925/2000Z
2. BFR 20040925/2000Z

VAA has the following options for "next advisory":

1. 20080923/0730Z
2. NO LATER THAN nnnnnnnn/nnnnZ
3. WILL BE ISSUED BY nnnnnnnn/nnnnZ

My take is that option 2 and option 3 of VAA have the same meaning (I believe I emailed ICAO on this recently) and therefore that VAA and SWA have essentially the same intent: either a specific time of issuance or a time before which the next issuance will occur.

The current representation allows this to be reported as both nextAdvisoryLatestTime and nextAdvisoryEarliestTime are optional - when there is a specific time being reported they are both present and set to the same time and when there is a "BEFORE" being reported only the nextAdvisoryLatestTime is present. I'm not sure that the TimePeriod/TimeInstant mechanism really captures the correct semantics: for a specific time this would be represented with the nextAdvisoryTime as a TimeInstant - for the "BEFORE" case there isn't a clear way to represent it.

For this and for VAA backwards compatibility reasons I think we are better keeping the current, independent TimeInstants.

[blchoy]

For this and for VAA backwards compatibility reasons I think we are better keeping the current, independent TimeInstants.

Alright. Seems that we have to accept this for the time being. :)