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

Space Weather Advisory and lat/lon polygons #217

Closed mgoberfield closed 4 years ago

mgoberfield commented 4 years ago

As Paul Chisholm reported (cbs-tt-avxml:1082) that SWXCs do not plan to issue lat/lon polygons to delineate space weather hazards initially, the current IWXXM schema and associated code registry table cannot properly indicate the use of them.

Element 'locationIndicator' is required by the schema but there is no entry in the WMO Code Registry table for a 'free-form' shape. As I see it, these are the possible solutions, in true Annex 3 style for indicating options:

Comments and suggestions welcomed.

Respectfully submitted,

mark

blchoy commented 4 years ago

As Paul Chisholm reported (cbs-tt-avxml:1082) that SWXCs do not plan to issue lat/lon polygons to delineate space weather hazards initially, the current IWXXM schema and associated code registry table cannot properly indicate the use of them.

I am thinking the opposite. The 'locationIndicator' is merely a symbolic indicator* of the volume described in the 'location'. So if SWXCs are not going to issue polygons then there will definitely be latitude band or daylight side descriptions and hence 'locationIndicator' should be non-empty. Only when SWXC issue advisories with polygons should our existing schema fail.

I agree with you there is still an issue with the schema and the most elegant solution is to make 'locationIndicator' optional. This is also backward compatible and that means we can implement it as a patch in 3.0.1. The laziest solution is to use a nilReason, as codelist entries are already nillable.

[* This also means that 'locationIndicator' is functionally redundant in the representation]

mgoberfield commented 4 years ago

I wasn't suggesting that because of this problem with the schema, the SWXCs aren't going to issue advisories with polygons. I just strung words together badly. That sentence needed a few more words omitted or added for clarity. I try thinking like you Choy and it's hard. . . .

blchoy commented 4 years ago

Don't border my friend. There is a separate discussion via e-mail on the east-west extend of the latitude band on whether it should cross the date-line or not. I am including an example to elaborate this:

On Tiera's other question, and looking at space weather test advisories issued recently including today, I think there is a need also for some guidance on usage of longitude information when in combination with latitude bands.

See below extracts from recently issued advisories:

OBS SWX: 27/0008Z HNH HSH E180 - W180  |
OBS SWX: 16/0800Z HNH HSH W180-E180    |==> those two mean the same, no risk of confusion

OBS SWX:           23/0750Z HNH HSH W150 - W030 ABV FL340  |
FCST SWX  +6 HR:   23/1400Z HNH HSH W090 - W030 ABV FL340  |==> no confusion here, all longitudes are in the Western part of the globe

OBS SWX:           28/0740Z MNH MSH E150 - W165     ==> does it mean from E150 to W165, which is 45-degree large ?
FCST SWX  +6 HR:   28/1400Z MNH MSH E060 - W105     ==> does it mean from E060 to W105, which is 195-degree large ?!  From W105 to E060, instead, which is 165 degree large ? Possibly confusing.

OBS SWX:           28/1140Z MNH MSH E030 - W090  ==> does it mean from E030 to W090, which is 240-degree large ?! Or from W090 to E030, which is 120 degree large and looks more realistic ?

Correct me if I am wrong, but there is currently no specification on the ordering of the points in a gml:posList (e.g. from E to W) which can be used to determine whether the line is crossing the dateline side or not. Having said that, our use of aixm:AirspaceVolume in SWXA actually eliminates this issue as the exterior ring has to be counter-clockwise.

[To make it less confuse, the counter-clockwise requirement applies to the exterior ring of gml:Surface, which is being used in aixm:AirspaceVolume]

mgoberfield commented 4 years ago

Ugh. Really? So if a SWXC lists the polygon points in clockwise manner in the TAC, it has to be re-ordered in the <posList>? The same is true for VA clouds. Does Annex 3 have anything to say about this, or no?

blchoy commented 4 years ago

Does Annex 3 have anything to say about this, or no?

No. We may want to promulgate this later on. In fact, polygons in TAC SIGMET should be clockwise and I doubt very much that our IWXXM examples (should be counter-clockwise) are incorrect. :( Need to check.

moryakovdv commented 4 years ago

BTW, I was a little bit surprised when I found the counter-clockwise polygon specification in GML couple of month ago. May be we should describe it in a guidance to avoid confusing of developers? Or am I the only one who didn't know about that? =)

porosnie commented 4 years ago

If of any help, you may refer to the AIXM guidance: https://ext.eurocontrol.int/aixm_confluence/display/ACG/Perimeter+Encoding+Direction

blchoy commented 4 years ago

@porosnie do you know if there is any update to the 2016 version of OGC Use of GML for Aviation Data?

porosnie commented 4 years ago

Revision 1 is still the latest version. We have started working on a new version (revision 2), but there was not much progress yet. The plan was to keep in the OGC document only the profile definition. All the guidance naterial that is specific to the use of GML for aeronautical data (such as how to code an ArcByCentrePoint) to be provided through the AIXM coding guidelines.

blchoy commented 4 years ago

All the guidance material that is specific to the use of GML for aeronautical data (such as how to code an ArcByCentrePoint) to be provided through the AIXM coding guidelines.

Thank you for letting us know this plan. This also means that if there is any specific encoding requirements for the MET domain we will need to find a place for them. We will be reviewing our documentation real soon and this information comes at the perfect moment. :)

blchoy commented 4 years ago

Going back to the original question let's settle for a nil for iwxxm:locationIndicator for polygon only geometry:

<iwxxm:locationIndicator nilReason="http://codes.wmo.int/common/nil/inapplicable"/>

I will include this in the TAC-to-XML Guidance.

blchoy commented 4 years ago

Implemented in Version 3.0-dev.

mgoberfield commented 4 years ago

Since a decision was made I will do this for you, if that's okay and you haven't included the new guidance already.

blchoy commented 4 years ago

My proposed Chinglish discription:

No location descriptions provided
  If only polygons are given "locationIndicator" shall be empty with nilReason set to "http://codes.wmo.int/common/nil/inapplicable"

Feel free to change. :)

mgoberfield commented 4 years ago

Your Cantonese and English are perfect!