Closed braeckel closed 5 years ago
I am in favour of (2) as the ordering of XML elements does not necessarily align with the ordering of components in a TAC message but the entity/concept they represents. Perhaps something to add in the TAC-to-XML guidance too?
This is fixed in 3.0.0RC2.
This is a formalization of an issue reported by Kyran Dollard earlier this year. Kyran's original comments follow.
========
The IWXXM METAR elements pertaining to variation in wind direction (included if criteria are met):- <iwxxm:extremeClockwiseWindDirection ...> <iwxxm:extremeCounterClockwiseWindDirection ...>
have the potential to be misinterpreted - when doing a conversion from TAC and therefore possibly in a downstream application?
I say this because: (a) I have already seen a 'ROC translation service' and a 'commercial demo converter' do the opposite to each other during a conversion process, e.g. TAC has: 11005KT 070V130 etc and e.g.
ROC translation service produces this in the XML:
but Commercial demo converter s/w produces:
(b) the WMO 306 FM-15 definition for dndndnVdxdxdx (15.5.3) says " the observed two extreme directions between which the wind has varied shall be given for dndndnVdxdxdx in clockwise order" ...but the IWXXM 2.1 schema elements and their definitions would seem to imply the opposite sequence order(going by the ROC example)?
(c) finally a human (even an application programmer!) might be inclined to view the variation simply like this:
dndndnVdxdxdx e.g. 070V130 in METAR
=> Wind dir varying between these 2 directions… 70 degs and 'Clockwise'? from this value? ? until 130 degs -i.e. 'CounterClockwise' value? =
Basically, I wonder if the IWXXM schema definitions for these elements could be improved OR the sequence order changed so as to avoid any such misinterpretation?
========
Two fixes may be appropriate:
There does seem room for ambiguity with these two elements. I prefer option 2 as it would be a straightforward change with no significant backwards compatibility implications.