Versions Compared

Version Old Version 4 New Version 5
Changes made by

WILSON Scott

WILSON Scott

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Panel
titlePage Table of Content

Table of Contents

Info
titleVersion

This page concerns v2.0 of the Specification. Supporting material on v1.0 is <tbd>

Requirement

Panel
borderColorlightgrey
bgColorwhitesmoke
borderStyledashed

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

tbd
  • 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.