Task Status

This page is part of the ongoing SWIM communities of interest discussions. The content is working material. It should not be treated as final as it is still subject to review, comment and change.

This page handles FAQ answers that are a work in progress.

Where can I find the semantic correspondence reports for the exchange models

You can find the published version of various semantic correspondence reports at: https://airm.aero/developers/semantic-correspondences.html

How does a service description relate to a service level agreement

See Formal Arrangements.

How do I record the use of GRIB2 in my service

This best practice covers how to detail the use of e.g. GRIB2 in the service description.

SWIM-SERV-019 Protocols and data format

The selection of protocol and data format for this requirement must be consistent with the interface service binding SWIM-SERV-018.

The selection is found in the TIYP Specification (see diagrams below).

WS-Light
- no specific data format is required by the TIYP specification
WS-SOAP
- the service has to support XML (SWIM-TIYP-0029)
  - this applies to the messages that are exchanged by the service.
  - it is possible for the XML formatted message to embed a file.
  - SWIM-TIYP-0033 gives the content that can be embedded (e.g., as multipart files) based around MIME type.

Example

The document below contains recommendations concerning GRIB2 and WCS, (e.g. Content Type Headers). It explains the mechanism to exchange multipart type of messages for the HTTP extensions.

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwj5h7771pnxAhUXA2MBHTlhB1wQFjADegQIBRAE&url=https%3A%2F%2Fportal.ogc.org%2Ffiles%2F68769&usg=AOvVaw2rwkVSOFFFUjTX89tBOEPT

Best practice

Details on GRIB2 are captured for the data format requirement. In the service metadata schema use the exchangeSchema field for this.
If using WS-SOAP
- In the service metadata schema use interfaceBindingDescription field to explain GRIB2 is embedded in the XML messages.

Service metadata example

"serviceInformationDescription": {
...
 "exchangeSchema": [
  {
   "name": "GRIB2",
   "schemaLanguage": "coverage",
   "reference": "reference to GRIB2 standard."
  }
 ]
...
}

Service metadata example

"serviceInterface": [
 {
  "interfaceBindingDescription": "XML requests and replies. GRIB2 is embedded (as zipped files) into the reply messages.",
 }

in contrast to the above, here is what to do if using IWXXM...

Service metadata example

"serviceInformationDescription": {
...
 "exchangeSchema": [
  {
   "name": "IWXXM 3.0",
   "schemaLanguage": "XML",
   "reference": "https://schemas.wmo.int/iwxxm/3.0/"
  }
 ]
...
}

Options for the schemaLanguage are:

coverage. The message contains gridded/raster data. This is used for e.g. GRIB2 and netCDF files.
image/map. The message contains a rendered, geo-located image/map. This is used for e.g. JPEG, PNG and SVG files.
XML. The message contains non-gridded data. This is used for e.g. IWXXM.

SWIM-SERV-022 Information definition

The requirement expects the content of the service payload to be defined. It is here that the content of the GRIB2 file e.g. turbulence should be defined. However, GRIB2 is a standard owned and defined for the MET domain, not the Aviation MET domain. Therefore it is out of scope of the AIRM.

Best practice

Define the essential aspect of the information being exchanged e.g. turbulence. In the service metadata schema use the informationDefinition field for this,
Ensure this essential aspect if defined in accordance with the AIRM.

Service metadata example

"informationDefinition": [
 {
  "name": "Turbulence",
  "description": "Atmospheric flow regime characterized by chaotic and stochastic property changes. This includes low momentum diffusion, high momentum convection, and rapid variation of pressure and velocity in space and time. (urn:aero:airm:1.0.0:LogicalModel:Subjects:Meteorology:Turbulence)",
  "airmConformant": true,
  "airmVersion": "1.0.0"
 }
],