WAFS SIGWX Forecast Readiness

[amilan17]

Branches

• https://github.com/wmo-im/iwxxm/tree/FT2021-2_WAFS_Significant_Weather_Forecast
• https://github.com/wmo-im/iwxxm/tree/FT2021-2_Meteorological_Feature
• https://github.com/wmo-im/iwxxm/tree/FT2021-2_Common

Purpose

Validate for public consultation

Related Issues

[blchoy]

There may be potential simplification to the code lists used in this package. Currently we are using:

1. Common Code table C-1 - Only "Washington WAFC" and "London WAFC" will be referenced.
2. 0-08-011 (Meteorological Feature) - A number of them will be used, but it also lack "radiation" and "tropopause" required.
3. 0-11-030 (Extended degree of turbulence) - Only "Moderate" and "Severe" will be referenced.
4. 0-20-008 (Cloud distribution for aviation) - Only "ISOL_EMBD" will be used.
5. 0-20-012 (Cloud type) - Only CB will be referenced.

For (1), we could continue to use the code table or move it to an enumeration, as it is unlikely to have another WAFC(s) in foreseeable future.

    <!-- Originating centre of the collective -->
    <iwxxm:originatingCentre xlink:href="http://codes.wmo.int/common/centre/74"/>

For (2), we may need to make a new WAFS specific code list under codes.wmo.int/49-2 so that we could manage it without any hindrance.

    <!-- A list of all phenomena of all objects -->
    <iwxxm:phenomenaList xlink:href="http://codes.wmo.int/bufr4/codeflag/0-08-011/10"/>
    <iwxxm:phenomenaList xlink:href="http://codes.wmo.int/bufr4/codeflag/0-08-011/13"/>
    <iwxxm:phenomenaList xlink:href="http://codes.wmo.int/bufr4/codeflag/0-08-011/12"/>
    <iwxxm:phenomenaList xlink:href="http://codes.wmo.int/bufr4/codeflag/0-08-011/TROPOPAUSE"/>
    <iwxxm:phenomenaList xlink:href="http://codes.wmo.int/bufr4/codeflag/0-08-011/RADIATION"/>
    <iwxxm:phenomenaList xlink:href="http://codes.wmo.int/bufr4/codeflag/0-08-011/25"/>
    <iwxxm:phenomenaList xlink:href="http://codes.wmo.int/bufr4/codeflag/0-08-011/22"/>
    <iwxxm:phenomenaList xlink:href="http://codes.wmo.int/bufr4/codeflag/0-08-011/17"/>

            <!-- A Jet Stream Object -->
            <iwxxm:phenomenon xlink:href="http://codes.wmo.int/bufr4/codeflag/0-08-011/10"/>
            ... ditto other objects

For (3)-(5), we can continue to use the BUFR tables as they are pretty standard until we take action to copy all involved BUFR code lists to have them under the purview of our team.

            <!-- A Turbulence Object -->
            <iwxxm:phenomenonProperty>
                <iwxxm:DegreeOfTurbulence xlink:href="http://codes.wmo.int/bufr4/codeflag/0-11-030/10"/>
            </iwxxm:phenomenonProperty>

            <!-- A Cloud Object -->
            <iwxxm:phenomenonProperty>
                <iwxxm:CloudDistribution xlink:href="http://codes.wmo.int/bufr4/codeflag/0-20-008/9"/>
            </iwxxm:phenomenonProperty>
            <iwxxm:phenomenonProperty>
                <iwxxm:CloudType xlink:href="http://codes.wmo.int/bufr4/codeflag/0-20-012/9"/>
            </iwxxm:phenomenonProperty>

Views please?

[mgoberfield]

For 1) prefer an enumeration: it's concise and not likely to be opaque as a code table reference. If there is to be another WAFC spun up in the future, there should be sufficient time to update the enumeration within the schema and get it published (but that may be due to my inherent optimism). It is interesting that you used the code list concept 74 and not 93 for London WAFC and I don't see the backup WAFC (Washington) listed in that code table.

I concur with the remaining points.

[blchoy]

It is interesting that you used the code list concept 74 and not 93 for London WAFC

I got the code from the WAFS SIGWX Guide, which indicated that both could be used for UK WAFS.

That will not happen again if we change from a code list to an enumeration.

[blchoy]

@jkorosi asked why new schematron rules were added for code list class too which will never be used?

   <sch:pattern id="METAR_SPECI.AerodromePresentWeather">
      <sch:rule context="//iwxxm:AerodromePresentWeather">
         <sch:assert test="@xlink:href = document('codes.wmo.int-49-2-AerodromePresentOrForecastWeather.rdf')/rdf:RDF//skos:member/skos:Concept/@*[local-name()='about'] or @nilReason">Element in iwxxm:AerodromePresentWeather should be a member of code list http://codes.wmo.int/49-2/AerodromePresentOrForecastWeather</sch:assert>
      </sch:rule>
   </sch:pattern>

Normally, the name of code list class will never be mentioned as the class will be referenced by UML attribute names or association target role names, and therefore there is no need to create schematron rules for them:

<iwxxm:presentWeather xlink:href="http://codes.wmo.int/306/4678/DZ"/>

This is not the case with the introduction of WxObject, in which code list class will be directly referenced:

<iwxxm:DegreeOfTurbulence xlink:href="http://codes.wmo.int/bufr4/codeflag/0-11-030/10"/>

Therefore I changed the schematron rule generating script to create rules for checking code list entries against the code list class. Obviously, I have overdone it.

I have revised the rule generating script to suppress the creation of rules for unnecessary code list class, and commit to the FT2021-2-dev branch (Commit 24e7423).

[blchoy]

Obviously, I have overdone it.

A second thought popped up when I was taking a morning shower: As we are also introducing extension to code lists it is a reasonable assumption that some people may also be using IWXXM code lists in these extensions. They will not be able to reference these code lists via attribute name or association end role name but directly through the code list class name. If we leave them out in the schematron rules we will not be able to check their conformance as what we are doing with other (feature and data) classes.

The concern @jkorosi has is possible name clash. I think the chance is low as we have deliberately made the class names so wordy.

Any further observations from @jkorosi and folks? And views for rolling back?

[blchoy]

Implementation completed in IWXXM 2021-2RC1.