MeteorologicalAerodromeReportStatus and TAFReportStatus may need to be broken into two parts

[blchoy]

When studying #121, it was noticed that both AMD and CNL can be present at the same time:

TAF AMD YUDO 161500Z 1600/1618 CNL

A closer look at the template indicated that NORMAL, AMENDMENT and CORRECTION are statuses of a report while CANCELLATION and MISSING are part of or referring to the content of a report. The most important thing is that they can co-exist as in the above example, and a single TAFReportStatus will not be able to represent the above situation.

A similar issue occurred in METAR/SPECI where MeteorologicalAerodromeReportStatus has values NORMAL, CORRECTION and MISSING but a (content) missing report can be either a normal or corrected one.

May need to introduce a new attribute to hold MISSING and CANCELLATION (the latter for TAF only). Any suggestion (e.g. ContentStatus)?

[braeckel]

This change will also impact the Schematron rules, as I recall there are a number related to NIL and CANCELLATION.

I agree that it is probably best to split apart into a report "status" (AMD, COR) and a separate set of information related to "missing/cancelled/NIL" status. Note that on METAR/SPECI we currently have an "automatedStation" boolean attribute (for AUTO). For the missing/cancelled/nil info we have two representational options:

1. Add "cancelled", "nil", "missing", and whatever other boolean fields are required to the appropriate reports as optional attributes. This would not require any changes to the current "automatedStation" boolean but it may be wise to consider new Schematron rules to ensure that the appropriate co-occurence rules exist for these attributes (for example, if it is an AUTO report it shouldn't also be cancelled)
2. Try to combine AUTO and NIL cases into a single enumeration (for METAR/SPECI) and NIL/CNL (for TAF), I believe this is what you mean by the "contentStatus". Based on the contents allowed in the template I'm not sure the TAF case makes sense since they have a different set of contents (the END OF TAF IF FORECAST MISSING vs END OF TAF IF FORECAST IS CANCELLED). We would also need to consider if there are ever cases where NIL and either AUTO or CNL can co-occur. If there are such cases we could not use a single enumerated attribute to represent both being reported on the same report, since this representation would allow only one or the other option.

Overall I prefer option 1 as it makes it easy to carry the independent fields and I believe it is clearer what is being reported than having another, intermediate "contentStatus" type of attribute. So I suggest we remove from the current status and add new boolean attributes for each condition, along with new Schematron rules to prevent co-occurrence where necessary.

[blchoy]

@mgoberfield please correct me if I am wrong: MISSING is a concept for bulletin. During preparation if any of its constituent METAR/TAF reports are not available (i.e. missing), respective NIL messages will be used in place of the reports. So MISSING and NIL are basically one concept with intended application in two different places and in my opinion NIL should be preserved as it is part of Annex 3.

We probably don't need a Boolean attribute for NIL as we are already able to represent reports with nil content with empty elements and nilReasons.

What is left is CANCEL. Making reference to what we have done with CNL SIGMET (although we are using the now ambiguous attribute name "status"), a separate attribute should do the work. This could either be an attribute of Boolean type (e.g. with name "cancellation") to indicate whether the report intends to cancel a previous one, or an attribute of Enumeration type (e.g. with name "directive") to indicate the intention of the report (e.g. with an enum value of "CANCEL_PREVIOUS_REPORT").

To summarize (with attribute names of my choice):

1. NORMAL/AMENDMENT/CORRECTION

   <TAF ReportType="NORMAL">
   ...
   </TAF>

2. Nil report

   
   <TAF ReportType="...">
   ... (Empty content with nilReason)
   </TAF>

3. Cancellation (use attribute with Boolean type)

... (content similar to a nil report)

4. Cancellation (use attribute with Enumeration type)

... (content similar to a nil report)

[blchoy]

After thinking for a while, we may also want to incorporate additional attributes to materialize our wish to reference previous reports as mentioned in #46.

1. Normal report

   <TAF ReportType="NORMAL">
   ...
   </TAF>

2. Amendment or correction report (amendment being shown here)

   <TAF ReportType="AMENDMENT" ReportBacklink="--gml:id_of_report_being_amended--">
   ...
   </TAF>

3. A normal report to cancel previous report

   <TAF ReportType="NORMAL" ReportCancellation="true" ReportCancellationBacklink="--gml:id_of_report_being_cancelled--">
   ... Existing TAC reference to report to be cancelled will be retained
   </TAF>

4. An amendment or correction report to cancel previous report (correction being shown here)

   <TAF ReportType="CORRECTION" ReportBacklink="--gml:id_of_report_being_amended--" ReportCancellation="true" ReportCancellationBacklink="--gml:id_of_report_being_cancelled--">
   ... Existing TAC reference to report to be cancelled will be retained
   </TAF>

So the case mentioned at the top of this issue, viz "TAF AMD YUDO 161500Z 1600/1618 CNL", should lies with Case 4.

Both ReportBacklink and ReportCancellationBacklink are optional items and in initial implementation I think it is good enough to leave blank.

Views please?

[mgoberfield]

So long as these are optional fields for non-routine issuances, I've no objection. So the TAF, SIGMET and AIRMET schemas will drop their elements that reference previous/canceled time periods in favor of the these new attributes using the gml id instead? Does this includes schematron rules that attempt to enforce the appearance of optional fields in non-routine issuances?

[blchoy]

In a discussion in the Google group , Patrick expressed his concern from the producer perspective that the filling up of the backlinks will be costly to implement and it will even be a greater challenge for translation centres. At the same time, Tero also made a point from the consumer's view point that the backlinks may be able to help locating previous reports. My gut feeling is that improving references to previous reports is something likely to be welcomed but it is not mature enough to implement right now (even though we only need to introduce two optional attributes). As there is no urgent need to have backlinks, I will take them out until version 3.1.

[mgoberfield]

Certainly it will always remain a challenge for translation centers to make references to previous reports, whether the gml ids, or unique content of the previous report are used as is the case now. That's why I prefer them to be truly optional and not have schematron rules for any references to previous reports in those cases, e.g. TAF.TAF-4 rule, unless I am overlooking something. But I agree that we can push this to 3.1.

[blchoy]

The finalized version is as follow:

1. A new element iwxxm:reportStatus (which has 3 values 'NORMAL', 'AMENDMENT' and 'CORRECTION') has been added to the Report Class which is inherited by all IWXXM reports:

2. METAR/SPECI: iwxxm:status has been removed and boolean attribute isNilReport has been added:

3. TAF: iwxxm:status has been removed and boolean attributes isNilReport and isCancelReport have been added:

4. SIGMET and AIRMET: iwxxm:status has been removed and a boolean attribute isCancelReport has been added:

5. TCA, VAA and SWA: iwxxm:status has been removed:

Note that in legacy reports, only cancellation reports need to make reference to previously issued reports; amendments and corrections are meant to override the previous reports. The schematron rules are adjusted as necessary. Multiplicities of certain elements have also been adjusted to allow missing elements in partially translated reports. There were minor changes to element names ordering.

This is perhaps the last item to be implemented in 3.0.0RC2 and I shall commit the schemas, etc in the coming days.

[blchoy]

These have been incorporated in 3.0.0RC2.

[ilkkarinne]

No need to re-open this old issue, just for documentation: it seems that the isNilReport attributes mentioned here were never incorporated into the IWXXM 3.0 XML Schemas for TAF, METAR or SPECI.

I could not find the discussion or decision on this in any of the issues in this repository.

[mgoberfield]

Did you check TAC-to-XML-Guidance.txt?

METAR/SPECI NIL report A NIL report shall be represented by making iwxxm:observation empty with a nilReason of "http://codes.wmo.int/common/nil/missing"

TAF NIL report A NIL report shall be represented by making iwxxm:baseForecast empty with a nilReason of "http://codes.wmo.int/common/nil/missing"

Or does this not address your concerns?

[ilkkarinne]

Yes @mgoberfield, the guidance is clear in https://github.com/wmo-im/iwxxm/blob/v3.0.0/IWXXM/examples/TAC-to-XML-Guidance.txt, I just added a comment here since the last comments seemed to give a wrong impression on how the missing reports should be encoded in the final IWXXM 3.0.