Consistency of element naming and ordering across different types of reports

[mgoberfield]

The current advisories all have a "next advisory time" element.

TCA is the outlier with a 'expectedNextAdvisoryTime' element. The VAA and SpaceWx advisories have 'nextAdvisoryTime' element.

TCA schema uses different names for maximum wind speeds in the observed and forecast portions of the document. Changed the forecast one to be consistent. As a consequence the schematron rule was updated also.

Commit f09043a2d656e5fc1a0167b35e09d419f25fe732 and 8491cb0b2d77923bcd5c5b002819e4a57fd40769 fix these inconsistencies.

[blchoy]

Your post came at the right time. Previously I discussed with Aaron on the ordering of root level elements and I prepared a comparison (IWXXM_elements.docx) across different types of reports. While we will fixed those highlighted in yellow, we also noticed that there may be further alignment and optimization to improve the schemas. For example, iwxxm:analysis covers both observation and forecast in VAA and SWA but others are described in separate observation and forecast elements. Observations and suggestions are most welcome!

[blchoy]

I have include the following changes in 3.0.0RC2:

TCA:

• expectedNextAdvisoryTime -> nextAdvisoryTime
• The elements in iwxxm:observation and iwxxm:forecast describing the maximum 10-minute mean surface wind speed were aligned as maximumSurfaceWindSpeed
• The multiplicity of iwxxm:forecast has changed from [4] to [1..*] to cater for upcoming relaxation of the interval and total duration of the forecast

TAF:

• previousReportValidPeriod now located immediately after validTime

SIGMET:

• volcanicAshMovedToFIR now moved from SIGMET to VolcanicAshSIGMET

VAA: A complete revamp of the report to improve the representation including:

• Segregation of 'iwxxm:analysis' into 'iwxxm:observation' and 'iwxxm:forecast' to cater for the different in representations.
• 'iwxxm:observation' can now handle properly the situation VA NOT IDENTIFIABLE FM SATELLITE DATA with a nilReason 'noObservable' for 'iwxxm:ashCloud' and a new 'iwxxm:wind' section which has its own 'aixm:AirspaceLayer'
• An indicator showing whether the 'iwxxm:observation' is OBSERVED or ESTIMATED has been added
• An indicator showing 'NO VA EXP', 'NOT AVBL' or 'NOT PROVIDED' in 'iwxxm:forecast' has been added

[mgoberfield]

To @blchoy, and et. al., how about the following changes to VAA model? This change makes observed and forecast portions of the advisory explicit, so as to be consistent with other IWXXM schemas (based on this document).

The boolean 'estimated' is needed since Annex 3 allows for estimated (EST) DTG and VA cloud position. Otherwise, it could be set to 'false' or not set at all when VA cloud(s) is/are explicitly observed (and so indicated in the TAC.)

For the changes to VolcanicAshCloud featureType, the 'windLower(Upper)Limit(Reference) were removed (as decided/recommended here). In the case of VA NOT IDENTIFIABLE, a layer is mandatory. This information is now contained in the AirspaceVolume element.

So, in this case of "VA NOT IDENTIFIABLE", the new attribute 'notDirectlyObserved' shall be set to 'true', otherwise not used (or set to 'false'). The existing guidance for VAA cases in the TAC-to-XML-Guidance document can still be applied with appropriate changes as shown here.

'VA NOT IDENTIFIABLE FM SATELLITE DATA' Unidentifiable volcanic ash from satellite data shall be indicated with attribute notDirectlyObserved set to 'true'.

'NO VA EXP' When no volcanic ash is expected it shall be indicated with a "ashCloudExtent" with a nilReason of "http://codes.wmo.int/common/nil/nothingOfOperationalSignificance"

'NOT AVBL' When volcanic ash is not available it shall be indicated with a "ashCloudExtent" with a nilReason of "http://codes.wmo.int/common/nil/missing"

'NOT PROVIDED' When volcanic ash is not provided it shall be indicated with a "ashCloudExtent" with a nilReason of "http://codes.wmo.int/common/nil/withheld"

For your consideration.

[blchoy]

Oh @mgoberfield I just edited my previous post to indicate I have accomplished my modifications and even close this issue without noticing that you have put some questions after it. My apologies for that. What I have done can be summarized in the following diagrams which I will try to explain tomorrow during the telecon:

I am not good at naming and your views on new elements like 'phenomenonCharacteristic' and 'forecastStatus' are most welcome!

[mgoberfield]

@blchoy, my thoughts on your revised VAA model:

Need to indicate variable wind in the WindObservedOrEstimated featureType, so windDirection cardinality needs to be [0..1] and a boolean attribute 'variableWindDirection' added to signify that.

For VolcanicAshForecastConditions featureType, what shall forecastStatus value be when ash clouds are observed?

Also the cardinality of ashCloud elements should be [0..* ] for both observed and forecast components of the model. More than one ash cloud can be given in the analysis and forecast periods. See FVAU03ADRM-0424.xml for a real-world example in the VAA iwxxm-translation repository.

With your proposed model changes, no ashCloud element is necessary if forecastStatus is "NO VA EXP", "NOT AVBL" or "NOT PROVIDED" hence I suggest to make the ashCloud element optional for the forecasts.

V/R,

mark

[blchoy]

Thank you for your prompt reply Mark. I have included all your suggestions and the revised class diagrams are as follow:

[mgoberfield]

Hello Choy,

Both elements that use the enumerations you've defined above are required. Yet all entries of the enumerations are in the "negative" sense. I would add one positive entry for each. So for VolcanicAshObservableOrEstimatedStatus enumerated type, the entries would be "Identifiable" and "Not Identifiable". (Or consider changing this element and use a boolean attribute to convey this condition instead)

For VACloudForecastStatus (please consider changing to VolcanicAshCloudForecastStatus for consistency), the enumerated entries could be "Provided", "No Volcanic Ash Expected", "Not Available", "Not Provided".

I don't know if there's an established XML convention about whether the enumerations entries should be in upper-case letters or not.

And VolcanicAshCloudForecast featureType needs directionOfMotion and speedOfMotion elements.

For your consideration,

mark

[blchoy]

And VolcanicAshCloudForecast featureType needs directionOfMotion and speedOfMotion elements.

I am not too sure about this:

[mgoberfield]

Yes. You're right. I need caffeine...

mark

[blchoy]

@mgoberfield, I have revised the model (mostly) in accordance to your further suggestions:

Or consider changing this element (i.e. IDENTIFIABLE/NOT_IDENTIFIABLE) and use a boolean attribute to convey this condition instead

While this is binary right now, I don't know when it will become non-binary so my best bet is to keep this arrangement which also aligns with the forecast part.

I don't know if there's an established XML convention about whether the enumerations entries should be in upper-case letters or not.

Currently it is all caps with underscores in place of white spaces in between words in other reports so I suggest we continue this practice.

By the way, do you have any idea where (I mean horizontally) the flight levels are referring to in the wind report when we have 'VA NOT IDENTIFIABLE FM SATELLITE DATA'? I guest it refers to the location of the volcano but can't find any documentation on that.

[blchoy]

This has been incorporated into 3.0.0RC2.