-
Notifications
You must be signed in to change notification settings - Fork 1
DN 2019_01 P2
... goto Part 1
Development of the representation starts with the creation of an atomic container of meteorological phenomenon. The iwxxm:MeteorologicalFeature holds a single meteorological phenomenon with specific descriptions of (1) the originator, (2) the phenomenon, (3) the phenomenon's geometry and (4) the phenomenon's property. For geometry and property virtual-typing (see OM-XML implementation) is being employed; by making them anyType and constraint by schematron rules in accordance to the feature to be represented the greatest degree of flexibility could be achieved. Selected iwxxm:MeteorologicalFeature can be grouped under a iwxxm:MeteorologicalFeatureCollection for the representation of more complex meteorological situation. The following Class Diagrams show details of the arrangement:
While iwxxm:MeteorologicalFeatureCollection can be used directly, it is more likely that it will be extended into new features so that additional elements and constraints can be included to enrich the concepts to be represented. In the WAFS case iwxxm:WAFSSignificantWeatherForecast is being created by extending iwxxm:MeteorologicalFeatureCollection as below:
Some basic features and code tables to be used with iwxxm:MeteorologicalFeature have been developed. These include geometric features to mimic those from AIXM which could some times be complicated to use in the representation of meteorological phenomena in aviation terms:
There are also property types developed specifically for use with iwxxm:WAFSSignificantWeatherForecast:
WAFS-Example.zip is an example showcasing the eight types of meteorological phenomena in a iwxxm:WAFSSignificantWeatherForecast.
The first batch of XML files generated was used in the test. This include four T+24 forecasts on turbulence, jet stream, cloud and tropopause in four separate files. WAFCs intend to distribute all phenomena of a time step in a single XML file. On GIS it is normal to have a layer of a single phenomenon at a time step. To directly ingest the XML files distributed by WAFCs in future, a plug-in to the GIS software may be required to generate layers in accordance to the phenomena for the time step.
The test was conducted with QGIS 3.12.1. Ingestion of XML/GML data file is usually conducted through GDAL and version 3.0.4 was being used in the test. There are currently two GDAL OGR drivers, namely GML and GMLAS, that can process XML/GML files.
A. Ingestion via GDAL OGR GML driver
When an OGR command was invoked upon a XML/GML file, it will inspect its content and also the associated schema if reachable, create an auxiliary file with extension .gfs to indicate what data (geometric and attribute) will be retrieved and their XPATHs and continue with the operation of the command. .gfs files are editable and for most of the time needs adjustments in order to get the right attribute from the file. The following are findings during the test:
- The driver complained about the use of gml:CublicSpline and indicated it had no knowledge of it.
- When all gml:CublicSpline descriptions were replaced by gml:LineStringSegment in the XML file it could get through, but the latitudes and longitudes mentioned in gml:posList were only treated as strings instead of being a geometry entity. Further tests confirmed that a geometric object can only be decoded properly when geometry and other attributes were encapsulated by
<gml:FeatureCollection><gml:featureMember>
in the XML file. - As a group of wind symbols, each of which has geometry and attributes, is attached to a jet core object[Note 1], joint tables or a (fixed) list of attributes may be required to represent them in a layer. No tests had been conducted so far.
[Note 1: It is by design to have the wind symbols to be properties of the jet core as they are not intended to be used alone (e.g. wind symbols do not have descriptors for wind direction), or otherwise they should be represented individually by iwxxm:MeteorologicalFeature.]
B. Ingestion via GDAL OGR GMLAS driver
Similar to the GML driver but less configurable with regard to the extraction of attributes. No further study had been made.
To summarise, the existing GDAL OGR though extensively used as input and output interfaces for GIS software does not currently have a working GML driver for WxObject, albeit the gap seems to be small.