WIP: IWXXM Quantitative Volcanic Ash Product

[mgoberfield]

WIP: IWXXM Quantitative Volcanic Ash Product

[mgoberfield]

@blchoy offered the following suggestions to the QVA schema and resulting XML document:

• Use <gml:identifier> as a unique tag for the QVA product
• Illustrate the use of additional optional elements, like <boundingVolume> so that ICAO can evaluate all potential features in the QVA schema
• Re-design the "Volcano" <feature> to use the <phenomenonGeometry> element and add additional <phenomenonProperty> elements as needed.
• Provide instantiations (objects) of any QVA complex types defined in the QVA UML model for documentation purposes

Based on these comments, I will have a revised QVA schema and example no later than 14 January.

[Please add or correct anything I've written here, @blchoy]

[blchoy]

Thanks @mgoberfield for the excellent work. It is definitely my fault for not providing enough documentation for developers.

The intention for having <MeteorologicalFeature>...</MeteorologicalFeature> is to make available a universal container for all phenomena which can be referenced by its <gml:Identifier>. Take a fragment of the WAFS SIGWX forecast example as an example:

<!-- A Cloud Object -->
<iwxxm:feature>
    <iwxxm:MeteorologicalFeature gml:id="...">
        <gml:identifier>...</gml:identifier>
        <iwxxm:phenomenon xlink:href="http://codes.wmo.int/49-2/MeteorologicalFeature/CLOUD"/>
        <iwxxm:phenomenonGeometry>...</iwxxm:phenomenonGeometry>
        <iwxxm:phenomenonProperty>...</iwxxm:phenomenonProperty>
        <iwxxm:phenomenonProperty>...</iwxxm:phenomenonProperty>
    </iwxxm:MeteorologicalFeature>
</iwxxm:feature>

As a side issue, <MeteorologicalFeature>...:</MeteorologicalFeature> only takes this form when appeared within <MeteorologicalFeatureCollecion>...</MeteorologicalFeatureCollection>; there is a constraint (MeteorologicalFeature.MeteorologicalFeature-2) requiring the presence of other elements if used in a standalone way:

<iwxxm:MeteorologicalFeature gml:id="...">
    <gml:identifier>...</gml:identifier>
    <iwxxm:issueTime>...</iwxxm:issueTime>
    <iwxxm:originatingCentre>...</iwxxm:originatingCentre>
    <iwxxm:phenomenonCategory>...</iwxxm:phenomenonCategory>
    <iwxxm:phenomenonTime>...</iwxxm:phenomenonTime>
    <iwxxm:phenomenon xlink:href="http://codes.wmo.int/49-2/MeteorologicalFeature/CLOUD"/>
    <iwxxm:phenomenonGeometry>...</iwxxm:phenomenonGeometry>
    <iwxxm:phenomenonProperty>...</iwxxm:phenomenonProperty>
    <iwxxm:phenomenonProperty>...</iwxxm:phenomenonProperty>
</iwxxm:MeteorologicalFeature>

A volcano eruption is a phenomenon, so it could be described as below:

<iwxxm:MeteorologicalFeature gml:id="...">
    <gml:identifier>...</gml:identifier>
    <iwxxm:issueTime>...</iwxxm:issueTime>    <-- Issuance of the information on the erupting volcano
    <iwxxm:originatingCentre>...</iwxxm:originatingCentre>    <-- Originating centre of the information on the erupting volcano
    <iwxxm:phenomenonCategory>...</iwxxm:phenomenonCategory>    <-- Observation?
    <iwxxm:phenomenonTime>...</iwxxm:phenomenonTime>    <-- Eruption time?
    <iwxxm:phenomenon xlink:href="http://codes.wmo.int/49-2/MeteorologicalFeature/VOLCANOERUPTION"/>
    <iwxxm:phenomenonGeometry>...</iwxxm:phenomenonGeometry>    <-- Location of the eruption (same as the summit of the volcano if the eruption is well behaved?)
    <iwxxm:phenomenonProperty>...</iwxxm:phenomenonProperty>    <-- Description of the eurption
    <iwxxm:phenomenonProperty>...</iwxxm:phenomenonProperty>    <-- Description/pointer to description of the volcano
</iwxxm:MeteorologicalFeature>

I take back my suggestion in using <iwxxm:MeteorologicalFeature> to describe a volcano as it is a 'thing', not phenomenon.

Happy to discuss further.

[mgoberfield]

Thank you for your comments, @blchoy.

[mgoberfield]

Updated QVA UML model, schema and example in the attached zip file. Feedback welcomed.

QVA.zip

[blchoy]

Thank you @mgoberfield. I think it is great work.

I do have a few more points to discuss with you before going back to Karen:

Originating centre: There should be a list of centres with indication of their responsible areas. So the minimal one can be a link to the respective entry of the list:

<iwxxm:originatingCentre>
    <iwxxm:VolcanicAshAdvisoryCenter xlink:href="http://RegistryOfVAAC/ADRM"/>
</iwxxm:originatingCentre>

or in the extreme case if we have a registry of the universe:

<iwxxm:originatingCentre xlink:href="http://RegistryOfTheUniverse/VAAC/ADRM"/>

If this list is online, theoretically one can retrieve relevant information of the centre during processing of the message. I share the view that we should allow iwxxm:VolcanicAshAdvisoryCentre to carry some information of the centre (Karen has listed a few) to cater for offline operation. If we keep the "link + selected (redundant) information" approach the fragment should look like:

<iwxxm:originatingCentre>
    <iwxxm:VolcanicAshAdvisoryCenter>
        <iwxxm:CentreReference xlink:href="http://centre.registry/ADRM"/>
        <iwxxm:name>...</iwxxm:name>
            ...
</iwxxm:originatingCentre>

Multiple plumes: We need to understand from Karen if multiple plumes from a volcanic eruption will be described in a single message, and if we need to indicate different concentration polygons belong to the same plume. Ditto the observed plume and its forecast.

Details of eruption: What is the relationship between the indicated eruption information and associated VAAs? If this is just copying work can we also apply the "link + selected (redundant) information" approach too?

[blchoy]

There are other items requiring attention:

1. The codelist WMOCategoryCode may need to be extended to cover cases where a MeteorologicalFeatureCollection has different catetories of MeteorologicalFeature. For example, in an advisory (collection) there exists observations (feature) and forecast (feature).
2. Attribute codeSpace in gml:identity could be utilized to indicate the characteristic(s) of the feature (e.g. an authoritative source)
3. For fixed-time forecasts whether there is a need to retain placeholders for dissipated ash cloud.

[mgoberfield]

Based on the telecon with Karen Shorey (ICAO QVA WG representative), the UML model was revised to include the explicit ash density threshold of the cloud. The QVA schema and XML document have been updated to reflect this.

The updated contents are within the attached zip file. Feedback is always welcomed.

QVA.zip

[mgoberfield]

Based on additional comments from @blchoy, I have revised the UML model and XML example to use AIXM Unit complex type. The zip file containing the revised model, schema and example is provided here.
QVACI.zip

[blchoy]

I finally find some time to finalize the QVACI package. The following are my initial response to Mark's suggestions:

QVACI-rev.zip

[Deterville]

For your consideration I have enclosed the following items in the attached zip file so that you may be able to review the first draft of the QVA UML model and its XML schema.

From the schema and the example that the ICAO Working Group provides in the Word document, a QVA XML document was created. There are additional follow-up questions for the team and, if still unresolved, the ICAO working group to consider.

The items in the zip file are as follows:

1. From the ICAO Working Group, a Word document detailing the QVA product requirements: IWXXM QVA Schema Requirements.docx.
2. From those requirements, a UML model for the QVA product was created. This model leverages the tremendous work done by Choy for the WAFS Significant Weather product. The EA project file, icao-iwxxm-qva.eap, and corresponding diagram image file, QVA-UML-Diagram.png are provided. (I do not know if all TT-AvData members have Enterprise Architect, hence the PNG file.)
3. From EA and the UML model for QVA, the IWXXM QVA schema file is generated. I kindly request that you review qva.xsd for any errors or omissions. (The other supporting XSD files, common.xsd, measures.xsd and metFeatures.xsd are essentially unchanged from the 2021-2 release.)
4. Using the example of the ash cloud depiction/scenario in the Word Document (item 1), I've recreated these clouds in Google Earth. The KML file is provided if you have Google Earth on your computer or can use https://earth.google.com This extra step was done to provide semi-realistic latitude/longitude information in the subsequent XML document.
5. Based on the schema, an incomplete but still relatively realistic XML document was produced, Example_QVA.xml.

If you want to examine the XML files in OxygenXML application (or similar) change the schema location information in Example_QVA.xml to the correct path to the IWXXM QVA schema file on your computer, i.e. replace "C:/Users/Mark.oberfield/Desktop" with your path. The QVA schema and XML document validates. As of yet, there are no QVA specific schematron rules.

While building out the XML example, I had some questions regarding incomplete 24-hr forecasts and how that might be depicted in the document.

Please let me know if you have any difficulties with the files. QVA.zip

Thank you for update. 24 hr. incomplete TBD noted.