wmo-im / iwxxm Goto Github PK

View Code? Open in Web Editor NEW

47.0 25.0 22.0 39.34 MB

XML schema and Schematron for aviation weather data exchange

Home Page: https://old.wmo.int/wiswiki/tiki-index.php%3Fpage=TT-AvXML

Python 0.89% HTML 97.31% CSS 0.37% JavaScript 1.42%

aviation aviation-weather weather xml icao wmo gml pilot xml-schema schematron

iwxxm's People

Contributors

Stargazers

Watchers

iwxxm's Issues

Add changes from WIGOS requirements

Changes deriving from WIGOS requirements are to be documented and added to the repo

ref: https://software.ecmwf.int/issues/browse/AVXML-33

Created:
30/Sep/15 9:37 AM

Reporter
Enrico Fucile

nilReason for METAR and SPECI

Ensure that nilReason is a valid entry for METAR and SPECI observed variables.

Consider alignment of the ways XML entities are made empty with @nilReason support

It was noticed that UML Classes with stereotypes <<dataType>> transform into XML schemas with no empty content and @nilReason support (see Section E2.4.5 of ISO 19136:2007 for details). For the rest of the stereotypes since the corresponding XML schema serialization are extending GML types which include directly or indirectly attributeGroup "AssociationAttributeGroup" (support for using xlink), the resulting XML entities will automatically allow empty content and the use of @nilReason. To include support for empty content and @nilReason to <<dataType>> UML Class and others which have similar super classes like GML primitives, GML introduces relevant UML-to-XML schema serialization rule with the use of tagged value nillable="true" in UML attributes and UML association ends (see Section 8.2.3.2 of ISO 19136:2007). The latter arrangement, however, requires the use of xsi:nil="true" in an instance to signify that the entity is empty. The following indicates differences of the approaches:

With "AssociationAttributeGroup": <iwxxm:forecastWeather nilReason="http://codes.wmo.int/common/nil/nothingOfOperationalSignificance"/>
In accordance to Section 8.2.3.2: <iwxxm:prevailingVisibility xsi:nil="true" uom="N/A" nilReason="missing"/>

As the above may introduce confusion to implementors, it is necessary to consider whether a technical or documentary solution will be used to overcome this issue.

ref: https://software.ecmwf.int/issues/browse/AVXML-54

Reporter:
    B L Choy 

Created:
    06/Apr/17 7:01 PM

Fix conflict between SFC/FL550 and TOP FL550, fix ABV FLnnn, document SIGMET/AIRMET vertical extent encoding for all allowed TAC combinations

FLnnn, nnnnM, nnnnFT
This is typical for SIGMETs based on pilot reports, e.g. turbulence at the level in
which the airplane was. We suggest to set aixm:lowerLimit and aixm:upperLimit
to the same value in effect creating an airspace volume which has zero thickness.
If you agree with this suggestion please add comment into TAC-to-XMLGuidance.
txt and/or in schema documentation and create an examples TAC/XML
SIGMET to demonstrate it.

ABV FLnnn
The issue is that geometryUpperLimitOperator can have only value "ABOVE"
but "BELOW" is not allowed by Schematron

<sch:pattern id="SIGMET.EMC5">
<sch:rule context="//iwxxm:EvolvingMeteorologicalCondition">
<sch:assert test="(if(exists(iwxxm:geometryLowerLimitOperator)) then
(iwxxm:geometryLowerLimitOperator = 'BELOW') else true())">
SIGMET.EMC5: geometryLowerLimitOperator can either be NULL or BELOW.
</sch:assert>
</sch:rule>
</sch:pattern>
<sch:pattern id="SIGMET.EMC6">
<sch:rule context="//iwxxm:EvolvingMeteorologicalCondition">
<sch:assert test="(if(exists(iwxxm:geometryUpperLimitOperator)) then
(iwxxm:geometryUpperLimitOperator = 'ABOVE') else true())">
SIGMET.EMC6: geometryUpperLimitOperator can either be NULL or ABOVE
</sch:assert>
</sch:rule>
</sch:pattern>

SFC/FL550
We believe the example sigmet-VA-EGGX.xml is incorrect and should be changed
like this:

The comment “omitted lower limit implies that the volcanic ash cloud
extends to groud/sea surface” should be removed
Instead of omitting lower limit there should be aixm:lowerLimit with value
“GND” and uom set to either FT (or maybe FL).
aixm:lowerLimitReference element can be probably omitted in this case
The above is probably better in line with AIXM or Digital NOTAM specification. Also
Boris Burger commented on Google Group that omitting lower limit would create
conflict with representation of “TOP FL550”.

the official VA SIGMET
example http://schemas.wmo.int/iwxxm/2.0/examples/sigmet-VAEGGX.

<aixm:AirspaceVolume gml:id="av-va-fcst-position-EGGX-YYYYMM25T22Z"><!--
omitted lower-limit implies that the volcanic ash cloud extends to ground/sea surface
-->
<aixm:upperLimit uom="FL">550</aixm:upperLimit>
<aixm:upperLimitReference>STD</aixm:upperLimitReference>
<!-- shortened -->
</aixm:AirspaceVolume>

xml which actually contains translation of SFC/FL550 suggests
that the lowerLimit should be simply omitted in this case, quoting:
But I think that is wrong too - because how would we distinguish that
from vertical extent TOP FL550?TOP FL550 - The person writing the
SIGMET is not saying anything about the lower limit of the vertical
extent. In this case it makes sense to omit the aixm:lowerLimit and
aixm:lowerLimitReferenceSFC/FL550 - Here the forecaster is writing
explicitly SFC, he is not saying "unspecified lower limit"
The AIXM element aixm:lowerLimit supports special value GND
(see http://www.aixm.aero/sites/aixm.aero/files/imce/AIXM511HTML/AIXM/DataType_ValDistanceVerticalBaseType.html).
Wouldn't it be more logical to set the lowerLimit to GND and
lowerLimitReference to SFC when SIGMET contains "SFC/FLnnn"? To
avoid confusion with the "TOP FLnnn" case?
According to the response from Yves Ernotte from Thales Air Systems
Recommended encoding for SFC in AIXM is aixm:lowerLimit with
value = GND, uom ='FT' and no aixm:lowerLimitReference.
Best regards,
Yves Ernotte (Thales Air Systems)
Later Yves Ernotte commented that he took this suggestion from Digital NOTAM
Specification:
have taken this from the Digital NOTAM event specification chapter
“5.4 Rules for encoding/decoding vertical limits”
(http://www.aixm.aero/sites/aixm.aero/files/imce/library/Digital_NOTAM_Spec/digital_notam_event_specification_1.0.doc)
Note that this is only a recommendation and that the document writes:
The "...Reference" attribute shall be left empty in this situation.
However, even if another uom is used or even if the "...Reference"
attribute gets a value, they should be ignored by a recipient application
because they do not have any meaning in combination with these
coded values.
So the only mandatory information is aixm:lowerLimit = GND and
omitting it means “unknown“ to me which is not what we want.

This stems from cbs-tt-avxml:

Add SIGWX representations to IWXXM

As directed by the ICAO METP, add SIGWX representations to IWXXM

Create and/or release WMO Codes Registry scripts

In TT-AvXML-4 it was determined that a set of scripts to download WMO Codes Registry entries and cache them locally was necessary to support operational use cases where live access to the WMO Codes Registry could not be assumed. Operational use is starting and this type of script is therefore quite important.

The following capabilities must be supported:

Download a local copy of either the entire or a partial set of the WMO Codes Registry
Update the local copy with the current "live" content
Check whether a particular URL is currently valid (not deprecated) from the live site
Check whether a particular URL is currently valid (not deprecated) based on local cache content

ref: https://software.ecmwf.int/issues/browse/AVXML-20

Created:
29/Sep/15 9:24 PM

Reporter:
Aaron Braeckel

Provide training topics to the CAeM Expert Team on Education, Training, and Competence

During TT-AvXML-4 it was determined that training information should be provided to the ICAO/WMO CAeM that is meeting 30 November 2015 until 3 December 2015.

ref: https://software.ecmwf.int/issues/browse/AVXML-3

Created:
29/Sep/15 6:46 PM

Reporter:
Aaron Braeckel

Add schema/Schematron checks to ensure that extended content always has a web accessible schema definition

Add checks to ensure that all extended content blocks have a web-accessible XML schema. Without this check it is possible to leave off the schemaLocation and the validator will not attempt to validate extended content without a schema. This is a safety issue in that the extended content essentially cannot be validated and has no description (including human-readable description) for consumers to use. There are two approaches:

Use processContents="strict" on all extension elements. This may have the desired behavior but more research required. This may require making use of the xs:any element instead of the current anyType
Add a Schema or Schematron check to ensure that the top-level element under each extension element has an xsi:schemaLocation for that top-level element’s namespace. For example, iwxxm-us elements should have an xsi:schemaLocation on each element that indicates the location for the iwxxm-us namespace. If a schemaLocation is set then validation will ensure that it is web-accessible and correct. This would not guarantee that all contents are validated, just the top element, but if this was extended for all namespaces under the extension element might get tricky to implement (increasing the need for a namespace "whitelist", for example).

Assess the utility of GML 3.3 Simple Geometries

Evaluate whether the GML 3.3 simple geometries can be used to simplify the geometries used in IWXXM, in particular polygons.

ref: https://software.ecmwf.int/issues/browse/AVXML-21

Created:
29/Sep/15 9:25 PM

Reporter:
Aaron Braeckel

Add a WMO Codes redirect from 49-2/observation-types/iwwxm to 49-2/observation-types/IWXXM

As discussed in TT-AvXML-6 the observation-types register is in IWXXM as http://codes.wmo.int/49-2/observation-type/iwxxm but the only entry is http://codes.wmo.int/49-2/observation-type/IWXXM.

The solution identified was to set up a redirect from http://codes.wmo.int/49-2/observation-type/iwxxm to http://codes.wmo.int/49-2/observation-type/IWXXM.

Simplify cancellation and NIL cases

The current version of the schemas require a good amount of description for a relatively small message (CNL, NIL, etc.), mostly in the form of OM_Observation information. This should be simplified so that only the necessary information is carried in these cases.

ref: https://software.ecmwf.int/issues/browse/AVXML-17

created:
29/Sep/15 9:10 PM

Reporter:
Aaron Braeckel

Update SIGMET CNL rules to leave out VA and TC SIGMETs

The current Schematron rule SIGMET1 implies that SIGMET CNL should be used with VA and TC SIGMETs:

context="//iwxxm:SIGMET|//iwxxm:VolcanicAshSIGMET|//iwxxm:TropicalCycloneSIGMET"

However, Annex 3 does not specify that a CNL SIGMET should include a TC or VA component. For clarity this rule should be updated to just apply against //iwxxm:SIGMET.

This stems from cbs-tt-avxml:576: https://groups.google.com/a/wmo.int/forum/#!topic/cbs-tt-avxml/DtJ8rg2w9Sk.

ref: https://software.ecmwf.int/issues/browse/AVXML-53

Reporter:
    Aaron Braeckel 

Created:
    10/Jun/16 6:17 PM

IWXXM 2.1 - codes.wmo.int URIs missing

The following URIs are referenced by the files in schemas.wmo.int for IWXXM 2.1. The file type is in brackets after the URI. Most are in examples, but some are in the schema definitions.

The code lists on codes.wmo.int need to be complete before IWXXM 2.1 can become fully operational.

Combine iwxxm-collect.sch and iwxxm.sch

The contents of iwxxm-collect.sch and iwxxm.sch are almost identical. It would be clearer and easier to combine these files as long as IWXXM messages by themselves validate with the extra COLLECT rule.

If "unwrapped" IWXXM messages do not validate then either COLLECT Schematron can be changed or they should not be combined.

Simplify IWXXM schemas

There have been multiple comments over the past two years to the effect that IWXXM is unnecessarily complex, especially when compared to the original TAC messages. Some of this complexity is necessary and comes directly from the original TAC data, and some of it is unnecessary.

Reasons to simplify IWXXM include:

Easier comprehension and reduced implementation work for new implementations generating IWXXM messages
Easier comprehension by IWXXM consumers
Reduction in file sizes (bytes), and associated network bandwidth and latency reductions
IWXXM 3 will be the last chance for quite some time to make major structural improvements

Reasons not to simplify:

Backwards compatibility will likely be broken at multiple levels within IWXXM, and changes will need to be made to existing software for IWXXM conversion, exchange, and generation. Major software revisions will be necessary for moving from IWXXM 2 to IWXXM 3 if structural simplifications are made

O&M structure and its mismatch with IWXXM reporting constructs, the use of many dependent schemas (GML, sampling spatial, METCE, etc.), and heavily nested content all may be contributing to the sense that IWXXM is unnecessarily complex.

Removing the use of GML is one simplification option, but due to the many other advantages of GML it is not considered a feasible simplification alternative.

Ensure that there are mechanisms for local validation of WMO Codes Registry contents

At the ICAO AsiaPac IWXXM Workshop it was indicated that having local copies is an essential operational function, and when IWXXM goes fully operational with IWXXM 2.1 and particularly into IWXXM 3 in 2020 it is very important that data producers and consumers be able to validate WMO Codes Registry contents locally. There are thousands of producers and consumers who cannot reasonably make dynamic requests to http://codes.wmo.int whenever they receive a message.

There are two potential solutions:

The WMO Codes Registry has a full download function for all IWXXM codes or the entire registry contents
Add Schematron checks into IWXXM (probably somewhat incomplete) to ensure that a URL starts with "http://codes.wmo.int/306/4678", for example

Add issueTime on AIRMET and SIGMET

Per discussion on cbs-tt-avxml and discussion in TT-AvXML-6, TAC has the issue that the TAC itself is not self-describing and cannot be used without its WMO header.

To make IWXXM AIR/SIGMETs self-describing and usable with a WFS or other non-COLLECT environments it is desirable to add an issueTime. The TAC to XML guidance should also be updated to include a description of this difference.

Schematron rule TAF.TAF18 mandates the presence of iwxxm:cloud which should not be the case for CAVOK

Jean-François Menon of Meteo France reported that TAF.TAF18 mandates the presence of iwxxm:surfaceWind and iwxxm:cloud when iwxxm:baseForecast is present. For TAC, however, the cloud group should not be present when CAVOK is expected. To mimic this arrangement TAF.TAF18 should be revised.

Add TAC code mappings into the WMO Codes Registry

To allow for authoritative translations between TAC and XML, it is necessary to be able to look up a code entry (such as http://codes.wmo.int/bufr4/codeflag/0-20-008/3) and have an explicit mapping to its TAC form ('BKN'). In earlier communications with WMO Codes Registry maintainers the conclusion was as follows:

“…labels from SKOS 1; e.g. skos:prefLabel and zero or more skos:altLabel properties in addition to the existing rdfs:label property. RDF (& the registry itself) fully support provision of multi-lingual text. Additionally, for strings such as "BKN" we can add skos:notation 2 properties”

It is probably also necessary to document how IWXXM users might check this information and potentially provide a script to check and/or download them with the IWXXM release.

ref: https://software.ecmwf.int/issues/browse/AVXML-19

Created:
29/Sep/15 9:21 PM

Reporter:
Aaron Braeckel

Amendment 78

Amendment 78 ICAO annex 3:

Space Weather: #50

Add optional report ids for referencing cancellable, correctable, amendable, etc report types

There are currently loose practices around having unique sequence ids with SIGMETs in particular. For backwards compatibility IWXXM should retain the sequence number method as a mandatory mechanism, and as an improvement should be able to cancel/amend/correct by id. In the case of conflict the sequence number should take precedence, which should be documented in the schemas.

This is a conclusion after discussion of #18 .

Create new (more readable) WMO Codes tables for current bufr4 references

ICAO Annex 3 and IWXXM 2.x reference codes like http://codes.wmo.int/bufr4/codeflag/0-20-008/3 for "BKN". The current bufr4 code tables have several issues:

the URLs are opaque and there is no easy indication that 0-20-008/3 is equivalent to "BKN"
the code lists in BUFR include more options (in some cases) than are allowed in ICAO Annex 3

New code list entries should be considered (perhaps under an "ae" register) for all bufr4 code list references in the schemas.

Create a CI process for the IWXXM GitHub repository

Using TravisCI or another CI provider, set up a CI process for checking that in any Pull Requests and the current HEAD that all of the examples validate against the XML Schemas and Schematron.

Document the IWXXM external contribution process for public viewing

In TT-AvXML-6 it was agreed that the process for gathering/reporting issues will be to:

email the cbs-tt-avxml email list
once verified by IWXXM developers, a GitHub issue is created

For external contributions it was agreed that all examples should pass the CI process before being accepted into the baseline. A statement to the effect that all rights are passed to WMO would be good to make contributors aware.

This would be documented in the README.md file in the IWXXM GitHub repository, then copied to the WMO wiki.

Incorporate common XML approaches

The cross-XM coordination discussions have led to several recommendations regarding versioning, deprecation, and namespaces. Consider the use of each of the policies described in https://ext.eurocontrol.int/aixm_confluence/display/XMWIP/Overview.

Note that the namespace policy may be particularly problematic as it would suggest something like http://www.iwxxm.aero/schema/{X}.{Y} instead of http://icao.int/iwxxm/{X}.{Y}

Assess the use of intersecting geometries as a way of describing AIR/SIGMET areas

In TT-AvXML-6 the possibility of expressing SIGMET (and AIRMET) phenomena as an intersection of geometries was discussed. WG-MIE-4 asked TT-AvXML to consider this alternative. In discussion it became clear that this has impacts on forecasters and the AIR/SIGMET production process that is well outside the scope of TT-AvXML.

This task is to assess the feasibility and challenges of using the intersection of AIR/SIGMET phenomena (such as a TC circle) with FIR boundaries explicitly.

Discussed challenges include:

Consumers need to do their own intersection to find the actual area of impact rather than having an explicit geometry with the met condition in the relevant FIR
Nearby FIRs with the same phenomena may describe a different region for the same phenomena. While each FIR has primary responsibility for its region the different forecasts may end up being inappropriately used by consumers

Identify which nilReason is most appropriate for WMO Code Table 1079 option 99

An appropriate nilReason should be identified (either from the OGC set or from the WMO Codes Registry) for METAR depthOfDeposit in runway state:
"Runway or runways non-operational due to snow, slush, ice, large drifts or runway clearance, but depth not reported"

This is taken from WMO Code Table 1079 value 99.

ref: https://software.ecmwf.int/issues/browse/AVXML-10

Created:
29/Sep/15 7:57 PM

Reporter:
Aaron Braeckel

Space Weather

Add a new report type, with a new schema, to support Space Weather reports

Make all observed fields optional with a nilReason (such as METAR)

ICAO is not directing us to do this.

ref: https://software.ecmwf.int/issues/browse/AVXML-40

Reporter:
    Aaron Braeckel 

Created:
    20/Nov/15 4:31 PM

Edit examples to properly reference observable-property WMO Codes entries

As discussed in TT-AvXML-6, there are several cases where the observable property WMO Codes URIs in the examples are incorrect. Update all examples to use consistent URLs similar to those of the observation-types.

Two examples that are currently incorrect are:
http://codes.wmo.int/49-2/observable-property/metarSpeci/observation
http://codes.wmo.int/49-2/observable-property/sigmet/positionAnalysis

There are probably others. An entry in the release notes will be very important for this issue to clarify why the changes were made.

Look into whether RunwayState should be restructured

Based on #6 it is not clear whether the current structure of having any number of RunwayStates, each with their own snowClosure which closes the entire aerodrome is correct. This should be corrected if necessary, and the use of nilReasons instead of booleans should be considered.

Create sample visualization/presentation alternatives to TAC

Due to the fact that TAC may no longer be the only visualization of this type of information once the transition to XML has been completed, it was determined in TT-AvXML-4 that it is worthwhile to explore some of the alternative visualizations that might be used on a tablet, web site, or other user interface. For example, a tabular form, icons, etc.

It is likely that this will be useful input to ICAO for standardization and/or discussion.

ref: https://software.ecmwf.int/issues/browse/AVXML-18

Created:
29/Sep/15 9:15 PM

Reporter:
Aaron Braeckel

Correct TAC -> XML locations in examples

For creating XML examples from TAC, fractional degrees were assumed. However, ICAO Annex 3 specifies that TAC lat/lon locations be in minutes and degrees instead of floating point degrees. Many examples are likely incorrect, most notably AIRMET and SIGMET.

ref: https://software.ecmwf.int/issues/browse/AVXML-46

Reporter:
   Aaron Braeckel 

Created:
    12/May/16 9:26 PM

all IWXXM reports to be in COLLECT containers

Annotate the documentation of IWXXM to record that ICAO requires all IWXXM reports to be packaged in a COLLECT container.

WG-MIE decided that COLLECT should be used for all IWXXM reports, even for single reports.

Update wiki pages

The TT-AvXML wiki pages should be updated to include:

free and commercial XML tools
updated tutorials content
links to training
updated, more concise information on IWXXM 2.0

ref: https://software.ecmwf.int/issues/browse/AVXML-5

Created:
29/Sep/15 7:02 PM

Reporter:
Aaron Braeckel

Feedback for wmdr developers - COLLECT cannot handle collections of wmdr records

Developers working on the wmdr (representation of WIGOS metadata) found that COLLECT did not meet their needs for gathering several wmdr documents into a single container.

It is desirable to avoid multiple types of container, and thus modifications of COLLECT to address the problems identified by the wmdr developers are advisable.

Add AIRMET/SIGMET boundary point indexes that indicate the overlap with an FIR boundary

Due to the lack of a common aeronautical database among AIRMET and SIGMET data providers, it can be the case that two reports can be issued on either side of an FIR boundary for the same meteorological condition. Until the FIR boundary issue is completely resolved it can be the case that reports issued on either side of the FIR boundary may not completely match, leaving "holes" or overlapping conditions when combined. The long term solution for this problem is to have a consistent set of aeronautical information which is used by all AIRMET/SIGMET issuers, but in the interim another solution is needed.

It was determined in TT-AvXML-4 that data providers should at least be able to indicate which points in the AIRMET/SIGMET boundary are also boundary points for the FIR boundary. With this information downstream consumers have more information by which any differences can be reconciled between FIR points described in more than one SIGMET or AIRMET that cross an FIR boundary.

ref: https://software.ecmwf.int/issues/browse/AVXML-8

Created:
29/Sep/15 7:19 PM

Reporter:
Aaron Braeckel

Missing <quantity> tag defining quantity-kind (e.g. heightAtTopOfCloud) in the schemas

explicitly part of IWXXM 2.1?

Is this:

in the UML
in the schema
in WMO No. 306 Vol I.3 Common Code-table D-2 (errata may be required)

is there a bug in the export

Generate XML Schema 1.1 for IWXXM 3.0

Instead of generating IWXXM 2.0 in XML Schema 1.1 this ticket previously mentioned, it will be more beneficial to have this in upcoming pre-release version of IWXXM (viz 3.0RC1) and be published well before the next Annex 3 amendment cycle for technology preview and testing.

ref: https://software.ecmwf.int/issues/browse/AVXML-7

Created:
29/Sep/15 7:08 PM

Reporter:
Aaron Braeckel

Ensure that minimum information content of failed translation messages is correct

In ICAO METP working groups it was agreed that the minimum set of metadata for partially translated messages:

METAR: METAR (COR) CCCC YYGGggZ
TAF: TAF (COR/AMD) CCCC YYGGggZ
SIGMET/AIRMET: CCCC SIGMET | AIRMET ... VALID YYGGgg/YYGGgg
VAA: DTG, VAAC
TCA: DTG, TCAC

There are existing examples illustrating this (*-translation-failed) but these need to be checked against the minimum information above. Further, schema modifications may need to be made if there is a mismatch.

Also, as part of this activity it would be good to ensure that *-NIL messages are closely matched to *-translation-failed other than the extra translation metadata.

Create additional examples for each IWXXM product

The existing set of examples cover a good amount of the model, but additional examples are needed for validation of the model and as samples for IWXXM developers.

Specific cases that are needed include a "normal" SIGMET, all status types for each report (correction, amendment, cancellation, etc.), and all other major report types.

This should be started after IWXXM 2.0 modifications are complete to ensure that redundant work is not performed.

ref: https://software.ecmwf.int/issues/browse/AVXML-1

Created:
29/Sep/15 6:41 PM

Reporter:
Aaron Braeckel

Combine METAR and SPECI product to enable WFS dissemination

At the moment IWXXM includes two separate products for a METAR and SPECI that carry the same information. However, they cannot be disseminated in the same feature type of a WFS because they are two different XML elements. ICAO usage to date has combined METAR and SPECI into a single data stream, and as we move forward that seems likely to continue.

ICAO SWIM, NextGen, and SESAR all use or mention WFS servers for distributing IWXXM data. Therefore this is likely to be a significant issue once modernization activities start deploying WFS services.

Possible solutions:

Remove the SPECI element/product, add a boolean 'specialReport' flag on METAR
Make MeteorologicalAerodromeObservationReport concrete, remove METAR and SPECI elements, and put a mandatory 'specialReport' boolean flag on MeteorologicalAerodromeObservationReport

Both options are confusing because they are changing the way the products are represented as compared to the TAC representations. The correct information is carried but the concept of the METAR and SPECI product types are different.

I have sent a query to the WFS 2.0 group to ensure that my interpretation is correct that both METAR and SPECI cannot be used in the same WFS 2.0 featureType.

Created:
15/Oct/15 5:00 PM
Reporter:
Aaron Braeckel

Clearly document which versions of IWXXM are required for which Annex 3 Amendment

This could go in a Git repository documentation or on the WMO wiki, but is a more authoritative document needed?

Add Schematron rules to mandate the use of UUIDs

As discussed in TT-AvXML-6, it was agreed that we will use UUIDs for all gml:ids. Add Schematron rules to enforce this.

Remove amountAndHeightUnobservableByAutoSystem

Per email discussion with Jonathan Paul on cbs-tt-avxml, add a nilReason on AerodromeObservedClouds and remove amountAndHeightUnobservableByAutoSystem.

Summary of how TT-AvXML use Github

Action from WG-MIE meeting

create a 'README' on the github site with a summary of how TT-AvxML will use Github to make the development of IWXXM more transparent to the user community

Share this with WG-MIE for review and further discussion

Update IWXXM examples to use UUIDs

For clarity in operational use, update examples to indicate that UUIDs should be used in most places. In IWXXM 3 Schematron rules will be added to mandate the use of UUIDs.

Improve TAF BECMG time support

In TT-AvXML-4 Mark Oberfield noted that there are two times of interest on a TAF BECMG group: a transition period and a period when the phenomenon exists. Both may need to be represented on TAF, whereas only one is carried today.

"OM_Observation provides a time at which the procedure completed (the result time) and the time or time-period when the result is relevant (the phenomenon time).

The validPeriod defines the period during which this TAF is valid.

TAF HGK 221754Z 2218/2318 18007MPS 4000 BR SCT100

BECMG 2300/2302 NSW CAVOK

What is the phenomenonTime for the BECMG group? Is the TimePeriod two hours long? Or 18 hours from 00Z to 18Z on the 23rd?

If it’s the former (two hours), for a WFS request what forecast will be returned if user request conditions at 06Z on the 23rd for Hong Kong International Airport? If it’s the latter, then how will the two hour duration for the BECMG group be derived? (problem for converting TAF XML->TAC)

To my understanding of phenomenonTime, I believe the latter option is correct."

ref; https://software.ecmwf.int/issues/browse/AVXML-32

Created:
29/Sep/15 9:45 PM

Reporter:
Aaron Braeckel

Add explicit TL/AT/FM to METAR/SPECI Trend Forecast

Some ambiguity remains regarding how to interpret the trend forecast group portion of METAR/SPECI. Currently the TL, FM, or AT determination is carried only by the phenomenonTime and whether it is before or after other time portions of the trend forecast. In TT-Av-XML-4 it was determined to be less confusing to make an explicit option to indicate TL, AT, and FM for the relevant forecast change groups in addition to the current time indicators.

ref: https://software.ecmwf.int/issues/browse/AVXML-13

Created:
29/Sep/15 8:59 PM

Reporter:
Aaron Braeckel

Assess whether IWXXM coordinates should be in the Mercator projection

In TT-AvXML-6 it was mentioned that ICAO policy suggests the use of the Mercator projection in certain cases. This may imply that IWXXM examples should be in a Mercator projection.

If so:

which datum
which dateline
other Mercator parameters, if any
and therefore; which EPSG code

wmo-im / iwxxm Goto Github PK

iwxxm's People

Contributors

Stargazers

Watchers

Forkers

iwxxm's Issues

Recommend Projects

Recommend Topics

Recommend Org