The model should represent the information of aviation weather messages represented in both TAC and IWXXM formats. The direction on polygon points is specified differently in these formats:
IWXXM aixm:AirspaceVolume (affecting gml:Surface affecting gml:posList) requires polygon points to be counter-clockwise (AIXM Coding Guidelines: Perimeter Encoding Direction).
It must be de defined how these different direction requirements are handled without confusion. Currently the model does not opine on direction of polygons. This leads to problems if e.g. TAC parser reads a clockwise polygon into the model, and then IWXXM serializer reads the polygon from the model as is without reversing the direction.
Possible alternatives for a solution could be:
Declare model polygons to be always clockwise.
Declare model polygons to be always counter-clockwise.
Add a flag or a method in the model to determine if represented polygon is clockwise or counter-clockwise.
This could be developed further, if seen appropriate, providing additional methods like getExteriorRingPositionsClockwise() and getExteriorRingPositionsCounterClockwise()
The model should represent the information of aviation weather messages represented in both TAC and IWXXM formats. The direction on polygon points is specified differently in these formats:
aixm:AirspaceVolume(affectinggml:Surfaceaffectinggml:posList) requires polygon points to be counter-clockwise (AIXM Coding Guidelines: Perimeter Encoding Direction).It must be de defined how these different direction requirements are handled without confusion. Currently the model does not opine on direction of polygons. This leads to problems if e.g. TAC parser reads a clockwise polygon into the model, and then IWXXM serializer reads the polygon from the model as is without reversing the direction.
Possible alternatives for a solution could be:
getExteriorRingPositionsClockwise()andgetExteriorRingPositionsCounterClockwise()