search

wmo-im / iwxxm

XML schema and Schematron for aviation weather data exchange
https://old.wmo.int/wiswiki/tiki-index.php%3Fpage=TT-AvXML
48 stars 22 forks source link

SIGMET Readiness #250

Closed amilan17 closed 3 years ago

amilan17 commented 3 years ago

Branch

https://github.com/wmo-im/iwxxm/tree/FT2021-2_SIGMET

Summary and Purpose

Validate for public consultation readiness.

Related Branches

209 

241

blchoy commented 3 years ago

Referencing #209.

Further to the proposed changes so far, @jkorosi raised the question whether the existing schema can adequately represent WC and WA SIGMETs where the conjunction AND is being used. In some sense it is, for example:

image

YUDD SIGMET 3 VALID 251230/251830 YUSO-YUDD SHANLON FIR TC GLORIA PSN N22 W061 CB OBS AT 1200Z WI 050KM OF TC CENTRE TOP FL500 INTSF FCST AT 1800Z TC CENTRE PSN N2230 W06230 CB WI 060KM OF TC CENTRE AND OBS AT 1220Z WI N2230 W06045 -N2230 W06015 -N2200 W06030 -N2230 W06045 TOP ABV FL500 FCST AT 1800Z WI N2300 W06200 -N2300 W06130 -N2230 W06145 -N2300 W06200=

We can only group the OBS CBs (yellow ones) together in the same iwxxm:TropicalCycloneSIGMETEvolvingConditionCollection and the FCST CBs (red ones) together in the same iwxxm:TropicalCycloneSIGMETForecastPositionCollection, which apparently lacked the intrinsic connection between individual OBS and FCST CBs.

My general comment is that this is a deficiency, but information-wise the existing implementation can adequately represent the start and end phases in the corresponding TAC message.

@jkorosi proposed a non-breaking and possibly the simplest solution: Add an optional attribute to iwxxm:SIGMETPosition to link back to its ancestor in iwxxm:SIGMETEvolvingCondition.

<iwxxm:analysis>
    <iwxxm:VolcanicAshSIGMETEvolvingConditionCollection>
        ...
        <iwxxm:member>
            <iwxxm:SIGMETEvolvingCondition gml:id="OBSCloud1">
               ...
            </iwxxm:SIGMETEvolvingCondition>
        </iwxxm:member>
        <iwxxm:member>
            <iwxxm:SIGMETEvolvingCondition gml:id="OBSCloud2">
               ...
            </iwxxm:SIGMETEvolvingCondition>
        </iwxxm:member>
    </iwxxm:VolcanicAshSIGMETEvolvingConditionCollection>
</iwxxm:analysis>
<iwxxm:forecastPositionAnalysis>
    <iwxxm:VolcanicAshSIGMETPositionCollection>
        ...
        <iwxxm:member>
            <iwxxm:SIGMETPosition gml:id="FCSTCloud1" backlink="OBSCloud1">
               ...
            </iwxxm:SIGMETPosition>
        </iwxxm:member>
        <iwxxm:member>
            <iwxxm:SIGMETPosition gml:id="FCSTCloud2" backlink="OBSCloud2">
               ...
            </iwxxm:SIGMETPosition>
        </iwxxm:member>
    </iwxxm:VolvanicAshSIGMETPositionCollection>
</iwxxm:forecastPositionAnalysis>

Another solution based on comments from @jkorosi and @moryakovdv which is a breaking change but look closer to TAC is shown as below:

image

Views please? Especially on whether we choose to:

  1. do nothing and accept that this is an issue
  2. proceed with the simplest and forward/backward compatible solution proposed by @jkorosi
  3. proceed with a breaking change but closer to the current TAC representation
  4. work on yet another design.

[Post discussion note: The above changes missed the different observation time of the second CB (1220Z in the above example) from the observation time of the tropical cyclone centre + first CB (1200Z). Note 19 of the SIGMET TAC template state that "Each location and forecast position is to be preceded by an observed or forecast time". This gives flexibility to describing the situation but personally I don't see it necessary to describe situations beyond snapshots at the time of observation and forecast. In any case there exists solutions but they will definitely be breaking solutions.]

amilan17 commented 3 years ago

Not ready - this issue will be addressed in the next cycle

blchoy commented 3 years ago

We will also need to confirm next time on the changes we have made so far in https://github.com/wmo-im/iwxxm/compare/FT2021-2_SIGMET

blchoy commented 3 years ago

Even though we are rolling back the changes we have made to the form we have in IWXXM 3.0, we still need to amend the notes under iwxxm:directionOfMotion and iwxxm:speedOfMotion as mentioned in another post under AIRMET Readiness. This shall also make the version of SIGMET advanced from 3.0.0 to 3.0.1.

jkorosi commented 3 years ago

I realize that two issues remain unresolved:

  1. VA SIGMET -the erupting volcano is required by Schematron rule VolcanicAshSIGMET.VolcanicAshSIGMET-2, but the erupting volcano is an optional part of VA SIGMET. 
    <sch:pattern id="VolcanicAshSIGMET.VolcanicAshSIGMET-2">
  <sch:rule context="//iwxxm:VolcanicAshSIGMET">
     <sch:assert test="( if( (empty(@isCancelReport) or @isCancelReport = 'false') and string-length(@translationFailedTAC) eq 0 ) then( exists(iwxxm:eruptingVolcano) ) else( true() ) )">VolcanicAshSIGMET.VolcanicAshSIGMET-2: An ordinary report should also have iwxxm:eruptingVolcano</sch:assert>
  </sch:rule>
</sch:pattern>
  2. All SIGMET types and AIRMET - STNR movement - The GitHub issue #187 modified the TAC-to-XML-Guidance.txt for STNR movement:

    Movement or expected movement - STNR Stationary phenomenon shall be denoted with both iwxxm:directionOfMotion and iwxxm:speedOfMotion absent

The description in https://schemas.wmo.int/iwxxm/3.0/sigmet.xsd is not aligned with it. The same is for airmet.xsd.

<complexType name="SIGMETEvolvingConditionType">
    <complexContent>
        <extension base="gml:AbstractFeatureType">
            <sequence>
                ...
                <element nillable="true" name="directionOfMotion" type="iwxxm:AngleWithNilReasonType" minOccurs="0" maxOccurs="1">
                    <annotation>
                        <documentation>
                            This element refers to the expected direction of movement which
                            the phenomenon is moving towards, .e.g, "moving east".

                            When no movement is expected, this is a 
                            http://www.opengis.net/def/nil/OGC/0/inapplicable nilReason
                            and the speedOfMotion will be 0.

                            This element value is given in degrees from true North. Plane angle unit
                            of measure (uom) is "deg".
                        </documentation>
                    </annotation>
                </element>
                <element name="speedOfMotion" type="gml:SpeedType" minOccurs="0" maxOccurs="1">
                    <annotation>
                        <documentation>
                            The expected speed of movement of a meteorological condition.

                            When no movement is expected, this will have a value of 0
                            and directionOfMotion will have a
                            http://www.opengis.net/def/nil/OGC/0/inapplicable nilReason.

                            speedOfMotion can be provided in either two units of measures: "km/h"
                            or "[kn_i]" (knots).
                        </documentation>
                    </annotation>
                </element>
                ...
            </sequence>
            ...
        </extension>
    </complexContent>
</complexType>

The Manual on Codes (306) defines also requirements which are not aligned with intention of #187. It says that only should be absent. There is no requirement about .

blchoy commented 3 years ago

With regard to the unresolved issues in https://github.com/wmo-im/iwxxm/issues/250#issuecomment-857514140