This page concerns v2.0 of the Specification. This requirement is new in v2.0.

Requirement

Title

Geographical extent of information

Identifier

SWIM-SERV-090

Requirement

A service description shall include information about the geographical coverage of the exchanged information service payload.

Rationale

This allows information service consumers to understand the geographical coverage of the information being provided. This enables the assessment of the use of the service.

Verification

Completeness: Verify that the element is included.

Consistency: Not Applicable.

Correctness: Not Applicable. 

Examples/Notes

Note: The geographical extent may be expressed in terms such as of ICAO region, FIR, Aerodrome or a geographical bounding box.

Note: This requirement concerns the exchanged information service payload, not the applicability of the service itself.

Level of Implementation

Mandatory

Guidance

The geographical extent of the information can be expressed in various ways. For example it may concern a single ICAO Region (see ICAO Regions). However, it is also possible that it covers a combination of FIRs, ICAO Regions and aerodromes. Furthermore it is possible that the information covers the entire world.

Bounding Box

The use of the geographical bounding box raises special concerns.

  • The service description information supports the discovery and assessment of services based on the geographical extent of the exchanged information.
  • The geographical extent in a service description may be in a different coordinate reference system from the information that is exchanged by the service. 
  • The GeoJSON standard uses the World Geodetic System 1984 (WGS 84) [WGS84] datum, with longitude and latitude units of decimal degrees. This means that the longitude appears before latitude in the position. However, it is customary in ATM to have latitude before longitude - therefore, users need to be aware of this difference.
  • Translation to other coordinate reference systems may need to take place if a system is to understand the geographical extent correctly. There are established tools and software libraries for this so we need not worry as long as the input is clear.
  • When encoding the polygons:
    • encode positions of the exterior  boundary counter-clockwise and any interior boundary clockwise. (That's how it is done in GML for aviation data guidance).
    • it is assumed that the x, y coordinates are captured in the polygon and altitude (z) coordinates are covered in the two altitude properties.

Note: The geoJSON standardisation group is considering the support for different coordinate reference systems. However, at the moment it only supports the World Geodetic System 1984 (WGS 84) [WGS84] datum, with longitude and latitude units of decimal degrees.

Verification Support

Completeness

Check that:

[  ] The service description includes information about the geographical coverage of the exchanged information service payload.

Examples

The following example shows the content as a table.

geographical extent of informationaerodromeEADD

geometry

100.0, 0.0

The following example shows an extract of the content of a JSON file that conforms to the Service Metadata Schema. It shows the use of an aerodrome location indicator and is supplemented by a geometry.

"serviceCategorisation": {
 ...
 "geospatialCategorisation": {
  "aerodrome": ["EADD"],
  "geometry": {
   "type": "GeometryCollection",
   "geometries": [{
    "type": "Point",
    "coordinates": [100.0, 0.0]
   }
  }
 }
}

The following example is where the information is worldwide.

"serviceCategorisation": {
 ...
 "geospatialCategorisation": {
  "description": "Worldwide."
 }
}

The following example is for an ICAO region using the value published at https://reference.swim.aero/information-services/service-categories/CodeICAORegionType.html#EUR.

"serviceCategorisation": {
 ...
 "geospatialCategorisation": {
  "region": ["EUR"]
 }
}




Complete examples are available at Example service description.