AvXML-1.0RC1-Issues
This list is a summary of the comments received on AvXML 1.0RC1. Only the first entry in a "conversation" has been copied here. Follow the links to see any subsequent discussions on the topics.
The comments have been copied verbatim. WMO takes no responsibility for the views expressed in these comments.
| Id | Issue | Link | Status | Response |
| 1 | Temperatures between -0.5 and 0: coded as M00 in METAR. | Link to comment | Open | (See post 160) |
| 2 | Include examples of coverages in RC2. | Link to comment | Open | |
| 3 | http://data.wmo.int/def/nil-reason/nothingOfOperationalSignificance nilReason was created. This was intended to cover cases where a specific value was measured but was not deemed to be operationally significant such as "NSC" and "NSW". To support nilReasons the stereotype must be changed from a DataType to a Type in the UML model. Specific classes include: AerodromeObservedClouds; AerodromeCloudForecast. | Link to comment | Open | |
| 4 | Add location and identification to SAF features. | Link to comment | Open | |
| 5 | ObservablePropertyModel: should ObservableProperty/StatisticalQualifier@aggregationTimePeriod be type TM_PeriodDuration (from ISO 19108)? | Link to comment | Open | |
| 6 | CAVOK only suppresses CAVOK only suppresses Visibility, Cloud, RVR and Significant Weather in the TAC. | Link to comment | Open | |
| 7 | Wind direction should be specified as relative to true or magnetic north. | Link to comment | Open | |
| 8 | RVR out of range Manual on codes FM15 METAR/ FM16 SPECI covers runway visual range: 15.7.6 Extreme values of runway visual range Special codings are used when RVR is above or below set limits, or when the RVR is outside the range that can be measured by the equipment. It does not seem possible to record this. | Link to comment | Open | |
| 9 | I cannot find a way of coding missing values like for example /////KT. Is there a standard way of doing it in GML? | Link to comment | Open | |
| 10 | Description of "Met Basic" package contents is broader than the abbreviated name implies (all of meteorology, climatology, water - and, not currently in the description, space weather). Should the name be changed | Link to comment | ||
| 11 | Ordering of elements in XML documents does not match the order in the UML model. | Link to comment | ||
| 12 | METCE Procedure "CompositeMeasurementContext" over complicates the model without adding value. | link to comment | ||
| 13 | Cannot encode any text within the iwxxm:LanguageString type. | Link to comment | ||
| 14 | Why are all the TAFs, METAR/SPECI, SIGMETs etc Objects and not Features?. | Link to comment | ||
| 15 | Referencing a runway: more guidance is needed on how to refer to a runway - ideally this will be consistent with other elements of AIXM. | Link to comment | Open | |
| 16 | List of acceptable present weather codes. | Link to comment 1 Link to comment 2 | ||
| 17 | In the Observable Property Model the property StatisticalQualifier/aggregationTimePeriod currently is type 'Time' (from ISO 19103 basic types). However, it is recommended that temporal properties are defined using types from ISO 19108 Temporal Schema. Proposal to change StatisticalQualifier/aggregationTimePeriod to type TM_PeriodDuration (from ISO 19108). The GML encoding rule for TM_PeriodDuration implements this type as xsd:duration ... therefore a 10-minute period would be encoded as the ISO 8601 duration "PT10M". | Link to comment | ||
| 18 | The <Type> stereotype is intended to convey an abstraction that is used in the underpinning ISO/TC211 harmonised model; it should _not_ be used in Application Schema. The appropriate practice is to have _no_ declared stereotype (e.g. blank). This change will have no impact on the the derived GML schema. Also note that the stereotype <FeatureType> should be used for entities that you want to access and/or query; therefore it is likely that the 'report' classes should be defined as <FeatureType> (this echoes the comment from Debbie Wilson) | Link to comment | ||
| 19 | Whilst the use of XML attributes is not part of the GML standard it is a commonly used encoding practice; ShapeChange already supports this encoding rule using the tagged value 'xsdAsAttribute'. We use a combination of acceptXMLAttribute and allowXMLAttribute for this purpose. To avoid confusion in the wider community, recommend using _existing_ tagged values for expressing this encoding mechanism rather than creating a new one ... http://shapechange.net/targets/xsd/extensions/#rule-xsd-prop-xsdAsAttribute refers. Note that encoding a property as XML attribute means that "standard" GML software tools will not recognise the attribute as property of the DataType or FeatureType; but the real world impact of this limitation is (likely to be) minimal. | link to comment | ||
| 20 | The constraint expressed in AerodromeRunwayState is not valid OCL ... (note, this was just a random sample; there is no inference that all the other constraints _are_ valid OCL!) | Link to comment | ||
| 21 | {on behalf of Clemens Portele} i) Clemens has never seen or cannot recall seeing the rule in the ISO 191xx specifications prohibiting extension of types from ISO 19103 ii) the extension of types in ISO 19103 has been done before; see WXXM (developed by EUROCONTROL et al) as an example iii) the GML encoding adopted for the 'measure' classes in met-basic (eg. AirTemperature) is fine iv) strictly speaking, an ApplicationSchema _must_ contain feature types; however, the defacto practice is to declare packages as Application Schema even in the absence of Feature Types. Recommend declaring met-basic as an Application Schema. | Link to comment | ||
| 22 | {on behalf of Clemens Portele} The use of the extra tagged values for <CodeList> classes (e.g. 'vocabulary' and 'extensibility') is OK. The revision of ISO 19109 Rules for Application Schema (currently work in progress) will* permit Application Schema developers to use local or community specific tagged values. Vocabulary and Extensibility tagged values are used within INSPIRE; this seems like an appropriate reuse. Note that the tagged value 'codespace' is also often used to refer to an externally managed vocabulary, but this is also non-standard ... it is just a community convention. In any case, the controlled vocabularies we refer to are not always simple "flat lists" therefore 'codespace' does not _really_ have the appropriate connotations. Use of 'vocabulary' and 'extensibility' tagged values should be retained. Also note that GML encoding we have used is also OK. * Clemens is pretty sure this was the outcome of discussion, but could not find the exact minuted resolution to refer to | Link to comment | ||
| 23 | {on behalf of Clemens Portele} Recommend that where unit of measure is defined by Unified Code for Units of Measure (UCUM) it is preferable to use the symbol from UCUM rather than the HTTP URI ... e.g. - currently our examples show <iwxxm:airTemperature uom="http://opengis.net/def/uom/UCUM/0/Cel">27</iwxxm:airTemperature> and <saf:upperLimit uom="http://opengis.net/def/uom/UCUM/0/%5Bft_i%5D">55000</saf:upperLimit> (noting the nastiness in the second example of needing to encode '[' and ']' characters in the URI for the UCUM symbol [ft_i]) - recommendation <iwxxm:airTemperature uom="Cel">27</iwxxm:airTemperature> and <saf:upperLimit uom="[ft_i]">55000</saf:upperLimit> Where the unit of measure is _not_ specified in UCUM, the full URI is required (e.g. oktas and degrees-true ... and perhaps icao standard flight level) ... e.g. <iwxxm:directionOfMotion uom="http://data.wmo.int/def/uom/degrees-true">180</iwxxm:directionOfMotion> Subsequent note: also a problem for units of measure such as m/s, where the solidus is a separator in a URL. | Link to comment | ||
| 24 | Reporting wind gusts This is the current situation AerodromeSurfaceWind.windSpeed of type WindSpeedType AerodromeSurfaceWindTrendForecastType.windGustSpeed of type GustSpeedType AerodromeSurfaceWind.windGust of type GustSpeedType it is desirable to harmonise the naming to avoid the users spending time on searching the appropriate type. It should be AerodromeSurfaceWind.windSpeed of type WindSpeedType AerodromeSurfaceWindTrendForecastType.windGust of type WindGustType AerodromeSurfaceWind.windGust of type WindGustType or AerodromeSurfaceWind.windSpeed of type WindSpeedType AerodromeSurfaceWindTrendForecastType.windGust of type WindSpeedType AerodromeSurfaceWind.windGust of type WindSpeedType | Link to comment | ||
| 25 | In the conversion of metar to xml I have found that the runway state is reported for several runways. This is not allowed in the xml schema as only one runway state is defined. I think we should add more runway states. | Link to comment | ||
| 26 | As response to our tests und discussions I send our first(draft) result. I hope we can send more details end of next week. As attachments you can find a summary of questions and results (DWD_statements_first_iteration.doc). For clarification of some of our ideas, I have attached two schemas from DWD (airport_customer_telegram.xsd) and Deutsche Flugsicherung (dfsMetar.xsd). Additional to these results, i have a technical question/problem: We use the oxygenXML tool to valitate xml-metats. But we will validate (against schema and schematron rules) all incomming xml-metars automatically. Currently i have not found opensource libraries to valitate (xml schema AND schematron rules) xml-documents against a combinated xsd-document (xml schema with embedded schematron rules). If schematron rules exist as seperated document (like *.sch) i see solutions. If somebody can help, we are happy. Otherweise: Is it possible to config Fullmoon to separate schematron rules as *.sch during the translation the UML constaints into schematron rules? | Link to comment and attachments | ||
| 27 | Inconsistent use of "aviation" and "aerology" reviewing the XML schema using Notepad++, Altova XMLSpy and browers, I note the following statement in aeronauticalMeteorology.xsd, within <documentation> </documentation> Often the entities defined herein are specialisations of generic meteorological entities. [<font color="#ff0000"><i>Note the inconsistent use of "aviation" vs. "aeronautical"; please indicate preference</i></font>] The text in bold is my emphasis. However, regardless of which software used the effect of highlighting the intervening text (between the bold text) never occurrs. | Link to comment | ||
| 28 | RC1 does not include any extensions mechanisms so data producers or downstream middlemen may extend ICAO/WMO content. This is a crucial capability. This has been planned for RC2, but this is a reminder that this should be addressed. Note that this ties closely into the ongoing discussions around XML Schema 1.1 and the open content model. | Link to comment | ||
| 29 | Impacts of Amendment 76 I understand that this implementation is based on Amendment 75. Amendment 76 comes into force wef 0000 UTC 14 November 2013, and a number of changes are expected. As such, this implementation may quickly become out of date. What maintenance plans are in place to ensure that this technical standard does not diverge from the ICAO Annex 3 Technical Regulation? ---- Diagram "Context Diagram: SIGMETPositionAnalysis" from IWXXM/SIGMET package includes the following public note (in orange, top-left). "Used for forecast positions for VolcanicAshSIGMETs and TropicalCycloneSIGMETs" With Amendment 76 (effective 0000 UTC 14/11/2013) all other SIGMET phenomena will be eligible to have forecast position information. | Link to comment | ||
| 30 | I understand that many of the 'constructs' that are used in SIGMET have been ignored, (i.e. N OF, NW of a stated line with coordinates given etc), and that in the XML/GML schema explicit points will be given defining a polygon (or point in some intstances). In certain respects I think that is a forward thinking approach, but how will the conversion from existing constructs as identified above, and perfectly legitimate in TAG SIGMET be handled? Is there any suggestion that TAC SIGMET be forced to use explicit polygons/points beyond a certain date (Nov 2016, Nov 2019, Nov 2022??) to be more explicitly mapped against the GML/XML versions. | Link to comment | ||
| 31 | There are gaps and inconsistencies in the current SIGMET table {of ICAO Annex 3 / WMO No. 49}, and also conflicting opinions by ICAO Regional Offices themselves with regard to how SIGMET should be constructed. How is the variation in interpretation resolved? | Link to comment | ||
| 32 | number of SIGMETs simultaneously in force for a given FIR Documentation for class SIGMET from IWXXM/SIGMET package states: "A SIGMET (significant meteorological) report. SIGMETs report the occurrence and/or expected occurrence of specified en-route weather phenomena which may affect the safety of aircraft operations, and of the development of those phenomena in time and space. Only a single SIGMET of a given type (e.g., Thunderstorm) shall be in force within a specific FIR at any given time." There is no restriction on how many SIGMETs may be in force of any type within an FIR. Where has this misconception come from? | Link to comment | ||
| 33 | ambiguity on use of OBS and FCST for SIGMET Diagram "Context Diagram: SIGMETEvolvingConditionAnalysis" (from IWXXM/SIGMET package) includes the following public note: """Used for OBS and FCST conditions on all SIGMET reports""" ... the orange note in the top right. Thought this was a bit ambiguous. Just to clarify, you cannot have OBS AND FCST, and where are the references to the optional 'AT'? The options OBS, OBS AT GGggZ, FCST, FCST at GGggZ. This ambiguity is repeated in the documentation for class EvolvingMeteorologicalCondition (from IWXXM/SIGMET package): "An EvolvingMeteorologicalCondition is a result of a SIGMETEvolvingConditionAnalysis process, and indicates the presence of a specific SIGMET phenomenon such as volcanic ash or a thunderstorm along with expected changes to the phenomenon such as intensity, speed, and direction. These conditions are reported with OBS/FCST conditions on all SIGMET types." Please clarify. | Link to comment | ||
| 34 | interpretation of CB base in SIGMET Documentation for Class EvolvingMeteorologicalCondition (from IWXXM/SIGMET package) states: "TC TOP (ABV and BLW) conditions are represented by the vertical component of the geometry. For example: CB TOP FL500 is represented as a base of 0 and a top of 500FL." Consider the example given: CB TOP FL500 is represented as a base of 0 and a top of 500FL. The interpretation is strictly incorrect. There is no information regarding the base of the CB. CB rarely, if ever, has a base at the surface. The base is simply unknown – whether you want to make the assumption that the base is at the surface is up to you, but is not implied in the SIGMET. | Link to comment | ||
| 35 | SIGMET validity periods Documentation for property SIGMET.validPeriod (from IWXXM/SIGMET package) states: "The valid period for the entire report, including all observations and forecasts. Each observation/forecast also includes its own applicable period of validity" The statement needs clarifying. There are no separate validity periods within a SIGMET. | Link to comment | ||
| 36 | Documentation for property SIGMET.analysis (from IWXXM/SIGMET package) states: "SIGMETs may include the same phenomenon covering more than one area within the FIR, as well as observed and forecast conditions for each of these reported areas. All combinations of observations and forecasts of meteorological conditions, including changing conditions, are represented by their own SIGMETEvolvingMeteorologicalCondition." Despite the statement, there is actually no specified or agreed method for including other instances of the same phenomena within a single SIGMET. Amendment 75 to Annex 3 is incomplete in this regard, and Amendment 76 is not expected to improve things greatly. UK practice is to only include one instance in any one SIGMET, and to issue separate SIGMETs as necessary. | Link to comment | ||
| 37 | RMK prohibited in SIGMET Class SIGMET (from IWXXM/SIGMET package) includes property "humanReadableText". The documentation for this property states: "Human-readable, descriptive text that cannot be sensibly represented in any other form. This report element encapsulates the human-generated text that is intended for other downstream human recipients. All other elements of the report capture machine-readable information that can be anticipated in advance as part of the reporting structure. It is not valid to include any machine-readable information or extended content in this text under any circumstances. Human-readable text may be considered opaque to parsing software and should be used minimally. This text is not to be confused with Traditional Alphanumeric Code (TAC) form remarks ("RMK"), which have been used for many purposes beyond human-readable text." RMK is not permitted in SIGMET. Although this property "is not to be confused with RMK", it is not clear whether SIGMET should include the facility for inclusion of arbitrary text. Please clarify whether 'humanReadableText' is permitted within SIGMET class. | Link to comment | ||
| 38 | designation of LONG or SHORT TAFs Has there been any consideration with regard to explicitly identifying if a TAF is a long TAF or a short TAF? | Link to comment | ||
| 39 | use of abbreviations for TAF forecast change indicator Enumeration AerodromeForecastChangeIndicator (from IWXXM/TAF package) provides unabbreviated terms; e.g. BECOMING. Maybe I misunderstand, but has somebody stated that these schemas should do away with the abbreviations BECMG, TEMPO, PROB30, PROB40, PROB30 TEMPO, PROB40 TEMPO, FM etc? Or are the references in the top right box simply mnemonics that map to BECMG, TEMPO etc? | Link to comment | ||
| 40 | use of forecast change indicator in TAF Class MeteorologicalAerodromeForecastRecord (from IWXXM/TAF package) includes the property 'changeIndicator'. A number of business rules need to be made explicit regarding the use of this property: 1) you cannot have PROB30 or PROB40 with BECMG or FM, and 2) the use of FM requires a full set of 'new' base conditions to be established. | Link to comment | ||
| 41 | reporting surface wind properties in TAF In reference to AerodromeSurfaceWindTrendForecast class (from IWXXM/Common package), the documentation for the property meanWindDirection states: "The forecast average wind direction. Not reported when winds have variable direction" Maybe I misunderstand the conventions of XML/GML, but the note to MeanWindDirection does not appear to be quite correct. If the wind direction is variable, then 'VRB' is reported, meaning variable. It is followed by the wind speed. Also note that the documention for property windSpeed does not make reference to it being an average (cf wind direction and reference to 'average'. Strictly, the averaging period is 10 minutes. To that end, the maximum wind speed is that maximum wind speed expected over a 10 minute period. Finally, it is also confusing to refer to this as 'TREND' in a TAF. Whilst both TREND and TAF may have some similarities is it not confusing to specify a component of TAF as being a TREND? If, to understandably minimise duplication and allow reuse of classes etc, can there not be a more generic title be identified? | Link to comment | ||
| 42 | documentation for minimum temperature in TAF The documentation for properties minimumAirTemperature and minimumAirTemperatureTime for class AerodromeAirTemperatureForecast (from IWXXM/TAF package) incorrectly refer to "TX" ... this should be "TN". | Link to comment | ||
| 43 | incorrect implication of CAVOK relating to surface wind Class MeteorologicalAerodromeForecastRecord (from IWXXM/TAF package) includes the following constraint: "if( ceilingAndVisibilityOK ) surfaceWind == NULL" This is incorrect. Surface wind has nothing to do with CAVOK. When CAVOK applies, then there will be no reference to visibility, weather or cloud (since CAVOK replaces all 3 parameters). If CAVOK is reported in the base conditions (or following the 'FM' change indicator) then a surface wind is mandatory. Thereafter significant changes to surface wind are mandatory regardless of whether CAVOK applies or otherwise. | Link to comment | ||
| 44 | METAR missing groups METAR As from the email exchanges, for ICAO, when an element is required, then it is not acceptable to have a NIL (or whatever the exact way it is indicated) for this element. Remarks: The requirement for an element to be always produced is indicated by the cardinality not at 0. The impossibility to have an indication of one element be missing due to some technical problems (whatever the exact problem and way to indicate it) and the application of a constraint will lead to the whole rejection of the XML METAR data, that will not be produced. Consequently, all the other elements of the data which are as well required (and sometimes of more operational importance ) will therefore not be produced due to the applied constraint. One direct consequence by the MET operator could as well be the cancellation of a TAF for the same location if it is considered that there is no way to keep the watch (as an example, due to occasional lack of Td ...). The WMO manual of code has explicit references about missing groups at least for AUTO METAR and for required elements. The uml (xml) model should be compliant with the WMO manual of Code. The ICAO expressed requirement to have a constraint on every required element leading to no METAR , if a required element ( ie cardinality not at 0) can never be indicated by "NIL" , should be fully assessed by ICAO. | Link to comment | ||
| 45 | TAF COR - in Type "TAF" should there be as well a new constraint " if(corrected) previousReportValidPeriod != null" ? identical remark with the following constraint " if( !amended AND !cancelled ) previousReportValidPeriod == null " >> What about Corrected TAF ? | Link to comment | ||
| 46 | TAF Type MeteorologicalAerodromeForecastrecord surfaceWind in Type "MeteorologicalAerodromeForecastrecord" if ( ceilingAndVisibilityOK) surfaceWind==NULL ), should "surfaceWind " be replaced by "cloud" ? | Link to comment | ||
| 47 | TAF Type MeteorologicalAerodromeForecastrecord prevailingVisibility in Type "MeteorologicalAerodromeForecastrecord" in " if ( ceilingAndVisibilityOK) prevailingVisibility ==NULL ), " " should "prevailingVisibility " be replaced by "prevailingHorizontalVisibility" ? | Link to comment | ||
| 48 | TAF AerodromeSurfaceWindForecast if ( ceilingAndVisibilityOK) surfaceWind ==NULL ) is not right & the "AerodromeSurfaceWindForecast" is indicated a 0:1 (link surfaceWind) due to that but it is always required (it should not be 0) | Link to comment | ||
| 49 | SIGMET VolcanicAshSIGMET / TropicalCycloneSIGMET / SIGMET Element gml:id VolcanicAshSIGMET / TropicalCycloneSIGMET / SIGMET Element gml:id : The uniqueness of the gml:id is not guaranteed if two SIGMET are issued for the same FIR at the same second. The addition of the SIGMET sequence number in the gml:id should guarantee the uniqueness. | Link to comment | ||
| 50 | SIGMET Status Why is the status attribute inside the tag ? | Link to comments | ||
| 51 | SIGMET VolcanicAshSIGMET eruptingVolcano VolcanicAshSIGMET eruptingVolcano Is there a nomenclature / list from which the erupting volcano name is chosen (in this case, reference / xlink maybe needed ) ? Or is it free text ? note : from ICAO DOC 9766 and in annex 3 Volcanic Ash Advisory template: name of volcano and volcano reference number: Volcano name (if known) and reference number (International Association of Volcanology andChemistry of the Earth’s Interior (IAVCEI))from the VONA template : Name and number (per Smithsonian database at http://www.volcano.si.edu/world/) | Link to comment | ||
| 52 | SIGMET humanReadableText is currently optional. It would be very useful, at least for testing purposes, to have the corresponding humanReadableText always available (until the xml becomes the official format) | Link to comment | ||
| 53 | SIGMET analysis : EvolvingMeteorogologicalCondition How do we know if it is an observation or a forecast ? Observation of Forecast is mandatory information, so it should appear clearly in the xml, not only in the gml_id. Is there a ruling to generate the gml_id ? What if there are several areas impacted, and observation and forecast ? At least for volcanic ash SIGMET and Tropical cyclone SIGMET, the SIGMET could contain : -one observation + one forecast (typical situation, OK with the current modelling) or -one observation only or -two forecasts or -one forecast and a no volcanic ash expected statement (as a next forecast-see last remark) How do we handle these with the analysis, and forecastPosition analysis ? Why is intensityChange attribute inside the tag ? | Link to comment | ||
| 54 | SIGMET cancellation In case of a SIGMET cancellation, as the analysis element is not optional, how do we handle a cancellation ? Do we have to have an analysis element anyway ? An empty one ? | Link to comment | ||
| 55 | SIGMET VolcanicAshSIGMET forecastPositionAnalysis In Annex 3 next amendment (76), the possibility of « No volcanic Ash expected » exists. How can we handle this with the current proposed forecastPositionAnalysis attributes ( we know we have to keep in mind only Amdt 75...) ? | Link to comment | ||
| 56 | TAF AerodromeForecastChangeIndicator - in "Enumeration" AerodromeForecastChangeIndicator " following Annex 3 2.3.2 APP 5-7, "TL" and "AT" exist but they are not found in template Table A5-1, and therefore not found in the model. The text in annex 3 and the Table A5-1 are not fully consistent. What should the model take into account ? | Link to comment | ||
| 57 | Relation between "airTemperature" and "dewpointTemperature" dewpointTemperature must never be higher as airTemperature. Proposal: %New schematron rule and UML constraint like: Schematron rule like: <sch:pattern xmlns:sch="http://purl.oclc.org/dsdl/schematron" name="MeteorologicalAerodromeObservationRecord6"> <sch:rule context="//iwxxm:MeteorologicalAerodromeObservationRecord"> <sch:assert test="notiwxxm:airTemperature) < number(iwxxm:dewpointTemperature?">Error: Dewpoint temperature higher then air temperature (forbidden)! </sch:assert> </sch:rule> </sch:pattern> | Link to comment | ||
| 58 | Direct using of GML-Types Dirk and i see conflicts between the direct using of GML-type like "gml:MeasureType" and range and accuracy of values (compliant to aviation): 1. Problem: E.g. windDirection is given as a whole number (integer) within the range of 1..360. Since AngleType is based on gml:MeasureType, which is a number of type double, there is no restriction of valid range of values nor accuracy. This is also an issue to other elements (e.g. windSpeed cannot have a negative value). Possible solution may be: 1. Use schematron rules and UML constraints to constrain sub-range compliant to aviation, like (schematron rules as example: <sch:pattern xmlns:sch="http://purl.oclc.org/dsdl/schematron" name="MeteorologicalAerodromeObservationRecord7"> <sch:rule context="//iwxxm:MeteorologicalAerodromeObservationRecord"> <sch:assert test="notiwxxm:surfaceWind//iwxxm:windSpeed) < 0)">Error: negative wind speed (forbidden)! </sch:assert> </sch:rule> </sch:pattern> <sch:pattern xmlns:sch="http://purl.oclc.org/dsdl/schematron" name="MeteorologicalAerodromeObservationRecord8"> <sch:rule context="//iwxxm:MeteorologicalAerodromeObservationRecord"> <sch:assert test="not(number(iwxxm:qnh) < 0)">Error: negative qnh (forbidden)! </sch:assert> </sch:rule> </sch:pattern> OR 2. Create a new "aviation-type" based on "gml:LengthType", "gml:SpeedType", ... ============= 2. Problem: If accuracy required, accuracy could be defined in the new aviation-types by using constraints based on a regular expression (e.g. as xsd pattern like: [\-]?\d{1,2}\.\d{1}) ) ============= 3. Problem: DataTypes like RVR (<iwxxm:meanRVR>), which are not a real discrete sequence of numbers could be better described by an enumeration of possible valid values. Examples from a DWD aviation project with an solutions like that are attached only for clarification ((see our email from 23 Jan; airport_customer_telegram.xsd, e.g. type "st_RVR_value") or DFS/DWD project (see our email from 23 Jan; dfsMetar.xsd, e.g. type "st_runwayVisualRange" </sch:assert> </sch:rule> </sch:pattern> <sch:pattern xmlns:sch="http://purl.oclc.org/dsdl/schematron" name="MeteorologicalAerodromeObservationRecord8"> <sch:rule context="//iwxxm:MeteorologicalAerodromeObservationRecord"> <sch:assert test="not(number(iwxxm:qnh) < 0)">Error: negative qnh (forbidden)! </sch:assert> </sch:rule> </sch:pattern> OR 2. Create a new "aviation-type" based on "gml:LengthType", "gml:SpeedType", ... ============= 2. Problem: If accuracy required, accuracy could be defined in the new aviation-types by using constraints based on a regular expression (e.g. as xsd pattern like: [\-]?\d{1,2}\.\d{1}) ) ============= 3. Problem: DataTypes like RVR (<iwxxm:meanRVR>), which are not a real discrete sequence of numbers could be better described by an enumeration of possible valid values. Examples from a DWD aviation project with an solutions like that are attached only for clarification ((see our email from 23 Jan; airport_customer_telegram.xsd, e.g. type "st_RVR_value") or DFS/DWD project (see our email from 23 Jan; dfsMetar.xsd, e.g. type "st_runwayVisualRange"" class="wiki wikinew number">? ============= 4. Problem: Observation for a mandatory element is not available or not reported (for what reason ever, failure of backup of backup sensor…) and this element is based on gml:MeasureType, it is not possible to encode an empty element nor a nilReason. Aviation-types may include a nilReason feature, including an enumeration of possible reasons. | Link to comment | ||
| 59 | Strongly typed vs. Weakly typed The AvXML format for the OPMET datasets is strongly typed. Environment Canada undertook an initiative to modernize its data exchange format in 2008. Out of this endeavour we initially created strongly typed XML schemas for different data types (eg: observation, forecasts, warnings, etc). But it became apparent shortly thereafter that the maintenance of these dataset specific schemas were needlessly complicated and expensive. Dedicated schema definitions, software bindings and libraries, and documentations needed to be created and managed individually for each dataset. Thus, it was decided to move away from a strongly typed XML approach to a weakly typed one. In the later approach, one .xsd was created as a general purpose container to hold any dataset from any data type, all the while conforming to the dataset’s specification as outlined by its authoritative body (eg: ICAO in the case of METAR, etc). This enabled us to create one set of software libraries to parse and encode XML instances, and one set of documents to supplement these instances. With this approach we were able to rapidly ingest and encode data from many distinct data networks. The weakly typed approach have also enabled us to share meteorological data with our clients and data providers in one uniform/common format, thus enhancing interoperability between data sharing parties. Although it might be too late to factor in these design considerations into the AvXML schema (since AvXML is well beyond the design phase and nearing a stable publication), we are raising this comment as a possible future consideration for other XML related work at WMO (eg: non-aviation datasets). Documentation, schema and samples of Environment Canada's Met-ML (Meteorological Markup Language) instances can be made available on request. | Link to comment | ||
| 60 | Only a single SIGMET (per type) per FIR Item: SIGMET : Public <<Leaf>> Package UUID: {E412FEC7-FA90-4b4f-BB89-ECBB773CDCB3} Statement: Only a single SIGMET of a given type (e.g., Thunderstorm) shall be in force within a specific FIR at any given time. Comment/Issue: This statement is not explicitly found in Annex 3. Table A6-1 indicates the footnote 21 next to the Location which means that element can be repeated as necessary. | Link to comment | ||
| 61 | Temperature and Dewpoint - METAR TAC specifications place these after the VIS and cloud goups. The XML schema requires this to be entered at the start of the observation Record segment. Temperature and Dewpoint - Reg 15.11.3 States that temperatures below 0 (zero) degrees shall be preceded by ‘M’ to indicate a negative temperature. The Schematron expects a whole integer and not a mixed char / int data type. Wind Speed - The wind speed in UK metars is currently reported in Knots (1 Nautical mile per hour) whereas in the UOM standard speeds of this type are expected in m s-1. The inclusion of Knots as the unit for wind speed causes a failure in validation. | Link to comment | ||
| 62 | Item: SIGMET : Public <<Type>> Class UUID: {1C3924B3-E438-4ab8-BF89-C5148CAFB866} Statement: Non-tropical cyclone and volcanic ash SIGMETs may report either an observation or a forecast. SIGMETs may include both an observation ("OBS") as well as a forecast ("FCST"). Issue/Comment: "Non-tropical cyclone"…what is that ? The second statement is misleading as written as it leads someone to think that a SIGMET can have both OBS and FCST simultaneously in a given bulletin. | Link to comment | ||
| 63 | Item: Public Note UUID:{216E7749-2AD2-4bd9-A11F-4E316EA5D6A2} Statement: Used for OBS and FCST conditions on all SIGMET reports Issue/Comment: This statement should say "Used for OBS or FCST conditions on all SIGMET reports" | Link to comments | ||
| 64 | Item: Public Note UUID: {D5C7EE7D-B7DC-49de-963F-21AB8DACCA95} Statement: The sampled feature for SIGMET is always an FIR Issue/Comment: Annex 3 allows the use of UIRs and CTAs as well. | https://groups.google.com/a/wmo.int/d/topic/cbs-tt-avxml/1FxjXn2FXNE/discussion | ||
| 65 | Item: TAF : Public <<Leaf>> Package UUID: {B0C787A8-5F53-4209-B721-28726BACAB9B} Statement: A Terminal Aerodrome Forecast (TAF) report is a routine aerodrome forecast intended for distribution beyond an aerodrome. TAF reports include base forecast conditions, and modifications to those conditions throughout the valid period. Issue/Comment: This statement should be replaced by the TAF definition found in Annex 3 Chapter 6 section 6.2.1 and 6.2.3. | Link to comment | ||
| 66 | Item: AerodromeAirTemperatureForecast : Public <<DataType>> Class UUID: {8DF2190B-28F0-40d1-8477-8F2B911FABED} Statement: An aggregation of air temperature forecast conditions typically reported together at an aerodrome, including the minimum and maximum anticipated air temperatures and when they occur. AerodromeAirTemperatureForecast is only reported on base conditions on a TAF, not change forecasts. Issue/Comment: The statement (and the detailed attributes) should indicate that Air temperature is optional and field may thus be missing entirely. | Link to comment | ||
| 67 | Item: AerodromeForecastChangeIndicator : Public <<Enumeration>> Class UUID: {B97CF00A-83EA-493b-902C-6B20F827029A} Statement: BECOMING Issue/Comment: the definition for the temporal change BECMG is not of that found in Annex 3 Appendix 5 section 1.3.4 | Link to comment | ||
| 68 | Item: AerodromeForecastChangeIndicator : Public <<Enumeration>> Class UUID: {B97CF00A-83EA-493b-902C-6B20F827029A} Statement: FROM Issue/Comment: Its is not FROM…it is FM | Link to comment | ||
| 69 | Item: AerodromeForecastChangeIndicator : Public <<Enumeration>> Class UUID: {B97CF00A-83EA-493b-902C-6B20F827029A} Statement: FROM Issue/Comment: the definition for the temporal change FM is not of that found in Annex 3 Appendix 5 section 1.3.6 | Link to comment | ||
| 70 | Item: TAF : Public <<Type>> Class UUID: {F5121C64-A503-4d54-8E95-6360540B6C06} Statement: A Terminal Aerodrome Forecast (TAF) report is a routine aerodrome forecast intended for distribution beyond an aerodrome. TAF reports include base forecast conditions, and modifications to those conditions throughout the valid period. Issue/Comment: This statement should be replaced by the TAF definition found in Annex 3 Chapter 6 section 6.2.1 and 6.2.3. | Link to comment | ||
| 71 | Item: Context Diagram: MeteorologicalAerodromeForecast Class:Type MeteorologicalAerodromeForecastRecord Statement: Constraints: (if ceilingAndVisibilityOK)SurfaceWind ==Null Issue/Comment: This statement says that no wind should be forecast when CAVOK is used. That is wrong. See Annex 3 Table A5-1. | Link to comment | ||
| 72 | Item: Context Diagram: Present Weather : Class diagram ID: {B2229DEF-E7A3-4930-93FC-5B43321C1DA5} Statement: N/A Issue/Comment: Why is this named "Present Weather" since the two classes represented here are Surface Wind.? | Link to comment | ||
| 73 | Item: Context Diagram: MeteorologicalAerodromeObservation Class:Type MeteorologicalAerodromeObservation Statement: Constraints: (if ceilingAndVisibilityOK)SurfaceWind ==Null Issue/Comment: This statement says that no wind should be reported when CAVOK is used. That is wrong. See Annex 3 Table A3-2. | Link to comment | See also comment 6 | |
| 74 | Item: SIGMET : Public <<Type>> Class UUID: {1C3924B3-E438-4ab8-BF89-C5148CAFB866} Statement: Only a single SIGMET of a given type (e.g., Thunderstorm) shall be in force within a specific FIR at any given time. Issue/Comment: This statement is not explicitly found in Annex 3. Table A6-1 indicates the footnote 21 next to the Location which means that element can be repeated as necessary. | Link to comment | ||
| 75 | reporting 'no significant change' in a METAR trend forecast: NOSIG instead of NSC Documentation for enumeration ForecastChangeIndicator (from METCE/Qualifiers package) states: 'Conditions typically reported as NO_SIGNFICANT_CHANGE (NSC) shall be encoded using the "nothingOfOperationalSignificance" nil-reason code.' The METAR regulation states that the abbreviation is "NOSIG" rather than "NSC". | Link to comments | ||
| 76 | clarification of constraint on reporting minimum visibility direction Class AerodromeHorizontalVisibility (from IWXXM/METAR package) includes the following constraint: { if( self.minimumVisibility NOT NULL ) minimumVisibilityDirection NOT NULL } This constraint needs to be amended; minimum visibility must be reported with a direction, except where the visibility is fluctuating rapidly (Annex 3, App 3, para 4.2.4.4b refers) whereby just the min vis is reported with no indication of direction. | Link to comment | ||
| 77 | OGC standards This is less of a comment but a notice of compliance. Environment Canada also chose the same set of core schemas to achieve XML representation of meteorological data. The OGC's Observation and Measurement (OM) and Geographic Markup Language (GML) schemas are heavily employed in Environment Canada's Met-ML (Meteorological Markup Language) schema. This ensures that when the AvXML needs to be generated for the OPMET datasets by Environment Canada, it will be seamless, since both Met-ML and AvXML are sharing the same core schemas. | Link to comment | ||
| 78 | Purpose of UML Class/Attribute note property In SESAR AIRM we use to capture the definition of an ATM concept inside the note property of a UML class/attribute. We use definitions taken (or slightly adapted) from an authoritative source (e.g. ICAO), so at the end the set of note properties of a model are shaped like sort of Dictionary By looking into the RC1 I see a different purpose. Classes descriptions do not always define the concept that the class represents, but rather describe the modelling purpose (e.g. "this class is..." ), or the usage of that class, or other side remarks (e.g. in the METAR theres an explanation that the METAR ad SPECI have same nature), or the reference to ICAO doc/page/table itself. I would clearly separate the definition of a concept from the usage remarks and the modelling aspects. I wonder whether all these additional info might be captured through tagged values. | Link to comment | ||
| 79 | AerodromeRunwayState, some findings 1) The nature of AerodromeRunwayState is a bit unclear: it looks like a mix of properties of both a runway and aerodrome (e.g. snowClosure is related to the latter); 2) I'm surprised that attribute "runway" is optional (according to the description, all RWYs could be closed for snow, so multiplicity would be zero then), since runway is kind of "primary key" for the info held in this class. If runway is NULL, then how to reference other RWY-related properties, e.g. depositType? 3) Also, there should be some constraint to link snowClosure and runway, as the existence of the latter attribute depends on the value of the former. | Link to comment | ||
| 80 | Codelists empty? I'm missing the context on the modelling activity, but many codelists seem empty (e.g. BreakingAction, RunwayDeposits and many more...). Is that done by purpose? | Link to comments | Code lists are held outside the model | |
| 81 | OCL syntax for constraints I'm not sure how far this release is intended to comply with OCL. According to the OMG OCL (2.3.1) specs, the arrow notation should be used to reference a set in a constraint, instead of the dotted notation, e.g. "self.affectedRunway->size()=0" instead of "self.affectedRunway.size=0" The latter would fail the validation (well, EA's OCL validation feature simply does not work, that's not a secret). Also "=" should be used for boolean expressions, rather than "==". Furthermore, I see different ways applied to evaluate whether an optional attribute is not present. Sometimes the "==NULL" is used, and sometimes the "size=0". I would recommend making a choice and applying it consistently. | Link to comment | ||
| 82 | Associations to codelist Typically a class property typed as a enum/codelist is held as a class member rather than as an association role. This sounds more sensible to me, style wise. However there are some exceptions in which there is an association to a codelist, e.g. MeteorologicalAerodromeObservationRecord.recentWeather. Is there an explanation to that? I would suggest to choose one pattern and apply it consistently throughout the model. | Link to comment | ||
| 83 | COnstraint on availability of cloud amount and base height I think there should be a constraint linking AerodromeObservedClouds.amountAndHeightUnobservableByAutoSystem to the availability of corresponding attributes (amount, base) in the associated CloudLayer class. | Link to comment | ||
| 84 | Constraint on RVR availability | Link to comment | ||
| 85 | Use of underscore in class names Class Visibility_Aero: is the underscore used by purpose here? Shouldn't it be deleted in this particular case? | Link to comment | ||
| 86 | EUROCONTROL Comments on the proposed models Despite the acknowledged recommendation, comments from several colleagues in the Organisation have been gathered in the attached EXCEL file which contains one sheet per package/schema plus one for general comments on the principles applied on the development of the models. Note that several findings come from issues encountered when generating code from XSDs for handling a representative set of METARs from all over the world. (Note, spreadsheet is available from the original post). | Link to comment | ||
| 87 | Is this complexity really needed ? Our feedback is of a more general nature. First of all thank you for the energy and dedication your team has in working towards this standardization effort. Our impression on the result of the work is strongly based on our analysis and tests of the XSD Schemas and with a particular focus on the use of OPMET in downstream, i.e. not as a collector of data to generate TAF METAR or SIGMET but as a distributor/processor of such messages once they have been created. Most of the remarks we initially had can be summarized with the following: For the purpose of OPMET it seems an overkill. A huge and complex amount of dependencies for the purpose to represent a quite simple set of information. This complexity becomes particularly obvious if one has a look at the java bindings: In order to parse a METAR which should result in something simple like this: METAR YUDO 221630Z 24004MPS 0600 R12/1000U DZ FG SCT010 OVC020 17/16 Q1018 BECMG TL1700 0800 FG BECMG AT1800 9999 NSW one needs to have more than 6400 classes as dependencies. Complexity is good if it can not been avoided or if the benefit it brings is big. For the scope METAR TAF and SIGMET we can not see such a benefit besides the fact that there is additional information when compared to the TAC counterparts. This additional information is however generally of poor interest to the Airmen. The wide use of referenced information (xlink and uom) even if it is often self-explanatory makes it difficult and time-consuming to process the information, we would prefer to have a self-contained message approach. Schematron: In principle we found the schematron approach good, but it seems there is the need to improve the used restrictions. For example we did change <sf:sampledFeature xlink:href="http://icao.int/id/aerodrome/YUDO" xlink:title="Fake Airport"/> to <sf:sampledFeature xlink:href="http://icao.int/id/XXXaerodrome/YUDO" xlink:title="Fake Airport"/> and it still passed validation. The conclusion is that if schematron has to be used then the restrictions should be more restrictive (we are aware that XPATH and XSL are quite weak in this). | Link to comment |