Dialog header

Digital Datasets - Evaluation Site Q&A Page

 

This page addresses the most frequently asked questions regarding the Digital Dataset trial. Should you have any further questions that are not covered here, contact us for additional assistance.

ID Title Subject Question Answer
1 Rhumb lines in AIXM output UK AIP Dataset Some geometries like 

<aixm:Airspace gml:id="id1185068”>

contain line segments with points in different CRS. This practice seems unorthodox and breaks our parser. I’m attaching an example, first point using mercator in meters and second point what seems to be WGS84 in degrees.
 
You think it would be possible to harmonize the output so that only one CRS is used?		 This is representation of a RHUMB lines in accordance with

https://ext.eurocontrol.int/aixm_confluence/

however based on further analysis, there seems to be a problem with the dataset export, where the srsName is being set on the 1st point and not set at the LineStringSegment level, an internal issue has been raised to investigate the problem further and work on a fix.
More info to follow.
2 Single point geodesic string airspace volume have started to export in datasets UK AIP Dataset UK AIP Dataset:

There are many instances of Airspace where the geometry is a ring with 2 identical points. A Ring should have 4 points at least. The 1st and last must be identical. 		 Following an investigation, AIS confirm the issue you raised is valid and options have been discussed with the CAA. These are the AIP aerial activities with single co-ordinates which unfortunately have escaped in the dataset export. The outcome is that these activities will have to be omitted from the export and we are in the process of updating the affected files online.
3 Rhumb lines in AIXM output UK AIP Dataset Where an airspace geometry is designed to follow a parallel of latitude, in the current dataset this is expressed very poorly, as a switch of coordinate reference system then back again. Note that AIXM has a proper way of expressing these rhumb lines and that should be used instead of attempting to switch projection halfway through a geometry. Two example airspaces where this is the case are EGWEST001 and EGSQ011. Please see the response to Feedback item 1. We are aware that Rhumb lines are not being presented correctly in the AIXM file and we are working to correct this.
4 RadioCommunicationChannel UK AIP Dataset The dataset contains over a thousand aixm:RadioCommunicationChannel entries but these are “orphaned” in that they are not linked to any other objects in the dataset. This is almost certainly an error. Missing from the dataset are aixm:AirTrafficControlService, aixm:InformationService, aixm:GroundTrafficControlService etc which are used to tie airspace and aerodromes to radio communication frequencies. The missing elements also contain the critical callsign information that a consumer needs to actually make use of the radio frequency data. Services linking RadioCommunicaitonChannel to another object are now included in the AIP dataset from AIRAC 02/2025 dataset.
5 Runway physical characteristics UK AIP Dataset Runway physical characteristics: as far as I can tell, these are incomplete in the dataset. I would expect everything in the AIP to be included, particularly runway end and threshold coordinates alongside declared distances (which I think are present). Thresholds in AIXM are coded as RunwayCentrelinePoint, runway end points and taxiway intersections are not provided to AIS and therefore not stored. Work is currently ongoing to update the CAA CAP 1732 document to included additional runway centreline positions
6 Route Segments UK AIP Dataset AIXM route segments should ideally have srsName specified on the aixm:Curve but this is missing. Instead it has been specified on the individual geographical points within, which might be valid, but since all the reference systems will be the same, it would be better to specify it once on the curve and this would be inline with how other producers specify it. This feedback has been registered for consideration as a future product improvement. 
7 xsi:nil=”true”  UK AIP Dataset In general there is a lot of wasted non-data in the export. AIXM is a wasteful file format to begin with, but looking through the data, a majority of it is empty elements (with xsi:nil=”true”) which could simply be omitted to save on storage and bandwidth. Agreed, however, The use of xsi:nil=”true” is aligned with ECTL common interoperable guidelines (https://ext.eurocontrol.int/aixm_confluence/display/ACG/Use+of+nilReason), which is used to meet ICAO PANS-AIM requirements in relation with the AIS data set that: “5.3.3.1.2 When a property is not defined for a particular occurrence of the subjects listed in 5.3.3.1.1, the AIS data sub-set shall include an explicit ‘not applicable’ indication.”

This can be observed in the DONLON sample https://github.com/aixm/donlon/blob/master/EA_AIP_DS_FULL_20170701.xml
8 aixm:RouteSegments UK AIP Dataset In a few instances, the aixm:RouteSegments have their aixm:availability missing. You have included it for the vast majority of route segments and its presence is vital for us to determine the direction of the route segment (forward, backward or both). It would be good if you could include this piece of information in the export. Missing information is on Q63, L602, P6, L18, L603. These omissions are intentional and indicate that there is a break in the route. The listed routes are not continuous.
These will be removed from the export
9 ATZ Ase Classification UK AIP Dataset ATZ airspace classifications: it is widely known that ATZ adopt whatever the classification is of the controlled airspace in which they fall. I therefore believe it is inappropriate to specify an explicit classification on the ATZ entities themselves, as you currently are. It gives rise to a problem when (in the case of Belfast and Newtownards) the ATZ lies partly in controlled airspace and partly outside. Since the airspace classification comes from the controlled airspace and not the ATZ, and having an airspace classification of “OTHER” (as you are currently doing) is not particularly helpful, I suggest removing the classification entirely. In AIXM we are able to associate an airspace with multiple classes which would appear to be a better modelling solution. These are remodelled in AIRAC 03/2025 .
10 EGD045 UK AIP Dataset EGD405 has its lower limit specified as 0ft STD. This is not valid and I believe it should be 0ft SFC as is the case with all other airspace whose lower limit is the surface. This coding error will be rectified in AIRAC 03/2025 dataset.
11 AIXM identifiers UK AIP Dataset AIXM identifiers: other publishers use the gml:id attribute on the root element to duplicate the gml:identifier element content that is the first child of the root element. In your data export you appear to be using an internal identifier in the gml:id attribute (such as “id4303619”) which is not used anywhere else in the document. I suggest adopting the practise of other publishers and making the gml:id the same as the uuid used to identify the object. At a system level this does not appear to provide any benefit. The other publishers (EAD) are generating the gml:id by prefixing the gml:identifier uuid with “uuid.” Which as a string is not used anywhere else in the document. The gml:id does not play a part in object identification as it is the gml:identifier uuid which is used for href operations.
12 CSV headers UK Obstacle Dataset The CSV files lack a header line with attribute names, so the meaning of each value has to be assumed or derived via comparison from the XML file. The Obstacle CSV format will be re-engineered to ensure headers are included
13 CSV Formatting UK Obstacle Dataset The provided attributes in the files appear to not be the same, as some of the CSV cover the obstacles in greater detail than their XML counterparts. For example, there is a detailed obstacle type, though identification of attributes is difficult because of the above point. We have no issues importing the CSV file to get the better completeness, but depending on the user, they might prefer the XML format and would then potentially miss out on additional attributes. We understand that the standardized nature of AIXM makes the provision of additional attributes tricky, so this is simply an observation. We have re-engineered the CSV so the content is driven from the AIXM, and we will try to preserve as much original information as possible by utilising additional AIXM not currently populated such as the vertical structure part type.
14 CSV Inconsistencies UK Obstacle Dataset We would also advocate for a consistent file structure among the provided CSV files, that is, using the same number and order of attributes in each file, to facilitate the automated parsing and import of the data. The current samples range from 16 to 27 attributes. We have re-engineered the CSV so the content is driven from the AIXM which ensures the output will be consistent even if there are empty columns due to the source files.
15 CSV Inconsistencies UK Obstacle Dataset For the same reasons, it would be beneficial to use the same attribute values across the different aerodrome files. For example, in EG_EGPH_EDINBURGH_OBS_DS_AREA_MULTI_FULL_20241031.csv, the area is provided as “Area2”, while in EG_EGSC_CAMBRIDGE_OBS_DS_AREA_MULTI_FULL_20241031_CSV.csv, it is “Area 2” (separated by a space). This doesn’t cause significant issues, but consistency would enable smooth automation, especially considering that new aerodrome files would get published using the same formats. Without consistency, the import tools have to be meticulously adjusted for each individual file. We have re-engineered the CSV so the content is driven from the AIXM which ensures the output will be consistent even if there are empty columns due to the source files.
16 CSV Errors UK Obstacle Dataset The file EG_EGCL_FENLAND_OBS_DS_AREA_MULTI_FULL_20241128.csv appears to only contain Latitude in WGS84 DMS format, but not Longitude. Both Latitude and Longitude are available in WGS84 DD formats, which on the other hand are missing entirely from the remaining files. This was a file construction error and has been corrected
17 CSV Inconsistencies UK Obstacle Dataset We noticed that the CSV files contain duplicate obstacles, as they might be published for both area 2 and area 3. This doesn’t seem to be the policy for the XML files, leading to a different total number of obstacles contained in the XML and CSV files for a specific aerodrome. For consistency sake, it would be preferrable to have the same policies applied to either file format. This is correct as the relationship for obstacle to obstacle area is one to many. The AIXM model allows one obstacle to be related to multiple areas, however as the CSV is a flat file this relationship has to be shown by duplication of the obstacle record.
We have re-engineered the CSV to better reflect the XML method
18 VRP in AIXM Format UK AIP Dataset The VRPs are not associated with their airfields other than with a linguistic note with the “friendly” name of the airfield. To avoid ambiguity and make the data machine-readable we need the ICAO code(s) of the associated airfields alongside each VRP. Could I submit this as an enhancement request please? Unfortunately, <AirportHeliport> and <Designated point> objects have a 1-1 relationship in AIXM, preventing us from using a consistent modelling solution across the entire VRP dataset. Several VRPs are associated with multiple Airports and this cannot be modelled, therefore we will seek CAA policy.