SWIM Supporting Material
SWIM-SERV-090 Geographical extent of information
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 information | aerodrome | EADD |
---|---|---|
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.
Status: Living Material