Amendment 79 to ICAO Annex 3

[blchoy]

This is a place holder for information and discussions on changes to IWXXM in relation to Amendment 79 to ICAO Annex 3. An impact analysis with initial thinking on the changes to be made can be found here.

[mgoberfield]

For VAA with the introduction of 'UNKNOWN's for some of these elements, our first attempt at how these changes are going to be represented in XML is a bit confusing to me (my usual state of mind).

For the \<iwxxm:stateOrRegion> element, if its 'UNKNOWN', the suggested action is to use the 'nilReason' attribute and set it to http://codes.wmo.int/common/nil/unknown. For the \<iwxxm:eruptionDetails> element, despite being a 'StringWithNilReasonType', the suggested action is to not use the nilReason attribute when its 'UNKNOWN' but just use the string itself as the value.

Is 'SFC' to be used only when ash is re-suspended? Would be nice to have a footnote attached to 'SFC' to make this clear. If that's the case, then perhaps summitElevation nilReason set to inapplicable?

[blchoy]

Thanks @mgoberfield for bringing up. I have been away for too long.

For VAA with the introduction of 'UNKNOWN's for some of these elements, our first attempt at how these changes are going to be represented in XML is a bit confusing to me (my usual state of mind).

I think that depends on whether there is a need to make an element not null. For example, while mentioning 'Tropical Cyclone NONAME' could be ambiguous, it is not possible to operate with 'Tropical Cyclone ""' at all. In this case the tropical cyclone name is being used as an identifier so it has to be non-null.

Looking from this perspective, neither \<iwxxm:stateOrRegion> nor \<iwxxm:eruptionDetails> is being used as an identifier (you can challenge "State or Region" is but I think the more important identifier on a VAA is the location of the volcanic ash cloud) so if they are null it will not lose information.

Views on the above interpretation are most welcome.

Is 'SFC' to be used only when ash is re-suspended? Would be nice to have a footnote attached to 'SFC' to make this clear. If that's the case, then perhaps summitElevation nilReason set to inapplicable?

I am not too sure SFC in \<iwxxm:summitElevation> can be represented by a null element and a nilReason "inapplicable". A formal method is to change this element from simple type to a complex type with the original summit elevation as one element and a boolean attribute to indicate whether it is at SFC if the element has a null value. Ugly but workable.

[mgoberfield]

I see that you revised the wiki entry.

Your comment suggests to me, then, that there is an overuse of StringWithNilReason types within the schemas. Would that be correct? If so, perhaps as part of the 3.1 update, those elements of StringWithNilReason types should be looked at more carefully and consider changing some to be ordinary character strings.

With regards to VAA summitElevation (of type LengthWithNilReason) potentially being set to 'SFC', at the time of my original comment, I had to come up with a means (albeit, indirect) to indicate that with the existing 3,0 schema. Since you deem the use of nilReason not a viable proposal/solution, I await the new complex type for summitElevation in a later version.

I will withdraw my PR on the IWXXM model.

[blchoy]

Your comment suggests to me, then, that there is an overuse of StringWithNilReason types within the schemas. Would that be correct? If so, perhaps as part of the 3.1 update, those elements of StringWithNilReason types should be looked at more carefully and consider changing some to be ordinary character strings.

A quick check of the use of StringWithNilReason confirmed my memory that it had been cautiously used so far (e.g. sequenceNumber and cancelledReportSequenceNumber in SIGMET). The only thing is that not all of them are explicitly described in the TAC-to-XML-Guidance.txt document.

With regards to VAA summitElevation (of type LengthWithNilReason) potentially being set to 'SFC', at the time of my original comment, I had to come up with a means (albeit, indirect) to indicate that with the existing 3,0 schema. Since you deem the use of nilReason not a viable proposal/solution, I await the new complex type for summitElevation in a later version.

My suggested implementation is as followed:

Case I: Summit elevation is provided

<iwxxm:summitElevation>
    <iwxxm:Summit>
        <iwxxm:elevation uom="m">1546</iwxxm:elevation>
    </iwxxm:Summit>
</iwxxm:summitElevation>

Case II: Summit elevation is not known

<iwxxm:summitElevation>
    <iwxxm:Summit>
        <iwxxm:elevation nilReason="http://codes.wmo.int/common/nil/unknown"/>
    </iwxxm:Summit>
</iwxxm:summitElevation>

Case III: Summit elevation is SFC

<iwxxm:summitElevation>
    <iwxxm:Summit isSurface="true">
        <iwxxm:elevation nilReason="http://codes.wmo.int/common/nil/inapplicable"/>
    </iwxxm:Summit>
</iwxxm:summitElevation>

I have to confess that I have no idea why SFC is being given here. As far as I understand its use is to facilitate the description of re-suspended volcanic ash but the latest ICAO Doc 9766 Handbook on the IAVW say something like this:

And there is no further mentioning of the use of SFC. I will buy a drink to anyone could enlightened us on this topic. :)

[mgoberfield]

I will ping my contact at Washington VAAC to see what they have to say about the discrepancy, but your suggested implementation/use cases for summitHeight element is fine with me.

[blchoy]

I think all the changes involving Amendment 79 should have been taken care of right now. This issue is hereby closed.