The change to the minimal metadata requirements

	Title	Change Proposal	Justification	Status	Notes
1	Update definition	Update Definitions page to include the different types of data sets. This can be a note in the ICAO data set entry. A data set outlined in ICAO Annex 15. Note: The different forms of ICAO data sets are listed in ICAO Annex 15 5.3.1.1: a) AIP data set; b) terrain data sets; c) obstacle data sets; d) aerodrome mapping data sets; and e) instrument flight procedure data sets.	The obstacle data set has different requirements from the others so needs to be defined on its own.	Implemented	The different metadata requirements can be found at Basic properties for obstacles. Discussed 16 July and no objections raised.
2	Change wording of DS-META-007 - Geographical extent of the data set on Metadata Requirements	Reword the requirement into two clauses: Each ICAO obstacle data set shall be provided together with metadata giving the geographical extent of the data set. Each ICAO data set, other than obstacle data sets, should be provided together with metadata giving the geographical extent of the data set. The new wording will be reflected on DS-META-007 - Geographical extent of the data set.	The obstacle data set makes "Area of coverage" mandatory. The tidy up of the table will ensure it is inline with the requirement/recommendation.	Implemented	Discussed 16 July and no objections raised.
3	Change the list of geographical elements to include.	The introduction on DS-META-007 - Geographical extent of the data set should become: This requirement is fulfilled by including a geographic description (GeographicDescription) as a clear, textual description of the data set's geographical extent. Best practice The inclusion of a bounding box (GeographicBoundingBox) or a polygon (BoundingPolygon) is a good practice in the GIS world. They are useful for applications that represent the data graphically, to set the initial window size. They are also facilitate the evaluation of the geographical coverage of a data set without having to parse and decode the full data set. The Obligation / Condition row in tables should become: Mandatory for obstacle data sets. Optional for other ICAO data sets. If provided: GeographicDescription is mandatory. Either GeographicBoundingBox or BoundingPolygon is recommended.	Reflects decision to concentrate on the provision of GeographicalDescription but allow the provision of other elements if available.	Implemented	Discussed 16 July. Proposal updated to reflect the outcomes.
4	New requirement for obstacle data sets covering integrity.	Add definition to Definitions: Data integrity (assurance level). A degree of assurance that an aeronautical data and its value has not been lost or altered since the origination or authorized amendment. (ICAO Annex 15) Add new requirement to Minimal Metadata Requirements: Each ICAO obstacle data set shall be provided together with metadata giving the data integrity assurance level of the data set. Add dedicated page with guidance. The table will use lineage. Of note: Implementing Instruction When adding the lineage statement state whether critical, essential or routine data integrity level is assured. Example encoding <gmd:MD_Metadata> ... <gmd:dataQualityInfo> <gmd:DQ_DataQuality> <gmd:scope> <!-- gmd:level is required by ISO 19115 (2003). This should use the value "dataset". --> <gmd:DQ_Scope> <gmd:level> <gmd:MD_ScopeCode codeList="https://www.isotc211.org/2005/resources/Codelist/gmxCodelists.xml#MD_ScopeCode" codeListValue="dataset">dataset</gmd:MD_ScopeCode> </gmd:level> </gmd:DQ_Scope> </gmd:scope> <gmd:lineage> <gmd:LI_Lineage> <gmd:statement> <gco:CharacterString>The routine data integrity level is assured.</gco:CharacterString> </gmd:statement> </gmd:LI_Lineage> </gmd:lineage> </gmd:DQ_DataQuality> </gmd:dataQualityInfo> ... </gmd:MD_Metadata> Update Appendix B_ Complete Informative Example to reflect the guidance.	See Basic properties for obstacles.	Implemented	Discussed 16 July. Proposal updated to reflect the outcomes. See notes below. Decision was to use lineage and the levels (critical, essential, routine) to fulfill the requirement. Obstacle data is routine so that is used in the guidance.
5	Rename DS-META-007 - Geographical extent of the data set, etc.	The page name should be updated to e.g. DS-META-007 - Geographical extent of the data set. This change should be applied to all the individual requirements pages.	The word "requirement" can be misleading. It is better simply to use the identifier.	Implemented	Discussed 16 July and no objections raised.
6	Update Appendix A_ Requirements Analysis to reflect final version of Annex 15 and PANS-AIM	Check the paragraph numbers used. Add the obstacle data set metadata requirements. Updated numbers should be reflected on Minimal Metadata Requirements as well.	Mostly tidy up.	Implemented	Discussed 16 July and no objections raised.
7	Update trace for DS-META-007 - Geographical extent of the data set on the Metadata Requirements page.	The requirement is traceable to PANS-AIM Table A6-2. Obstacle attributes for the obstacle data sets	The obstacle data set makes "Area of coverage" mandatory.	Implemented	Discussed 16 July and no objections raised.
8	Update guidance on Requirement 3_ Validity of the data set	Add guidance to clarify what is meant by validity in this case. The start of the validity of the data set is based on the "effective date" of its data. Although this is may be an AIRAC date, it can be any date. This is particularly true for obstacle data sets that do not need to follow AIRAC. The end of the validity of the data set is based on the date and time when the first data ceases to have effect. In many cases this will be at an indeterminate time in the future. The validity of the data set is different from the date and time when the data set is provided but is not yet effective (Requirement 2_ Date and time when provided). More information on baseline data and updates is available at Data set variants.		Implemented	Discussed 16 July. Proposal updated to reflect the outcomes.
9	Change the order of the two examples on DS-META-003 - Validity of the data set	Change the order of the examples as the "End date unknown" is the more usual case.		Implemented	Implemented without discussion as has no impact on anything else.
10	Add DS-META-000 - How to Provide Metadata to Metadata Requirements list	Add DS-META-000 - How to Provide Metadata to the Metadata Requirements page as it is currently not listed there.	We should not have a requirement that is not listed on the Metadata Requirements page.	Implemented
11	Add link to the obstacle requirements on the main page.			Implemented
12	Integrate the obstacle data set requirements	The following pages were added: DS-META-009 - Horizontal confidence level DS-META-010 - Vertical confidence level Applicability of Metadata Requirements changes were made to integrate the obstacle metadata to Definitions Metadata Requirements content came from [for deletion] Obstacle metadata requirements	Bringing all of the metadata requirements into one place to make easier to manage and understand	Implemented	Implementation will be explained on 13 April 2021
13	Resolved comments	Updated: Minimal Metadata Requirements introduction to refer to industry standards DS-META-002 - Date and time when provided to use gco:DateTime only DS-META-004 - Indication that this is an AIRAC update implementing instruction to also include "Non-AIRAC". This caused update to Applicability of Metadata Requirements for obstacles. Additional Elements Fulfilling ISO 19115 (2003) to include optional content to include in the abstract. Updated Appendix B_ Complete Informative Example to include this.	Clarifications and improvements from the group.	Implemented
14	Renamed pages to use consistent naming convention	Updated names from OB-META-xxx to DS-META-xxx for: DS-META-009 - Horizontal confidence level DS-META-010 - Vertical confidence level	Clarifications and improvements from the group.	Implemented

Notes on data integrity discussions

The group considered various inputs for the data integrity discussion.

ED-98C/DO-276C:

Integrity
Definition: Integrity of data is the degree of assurance that the data and its value have not been lost nor altered since the data origination or authorized amendment.
Data Capture Rule: The integrity of the data set shall be expressed, indicating the probability of any single data element having been changed inadvertently since the creation of the data set [OBST-R034].
NOTE: For more information on integrity, refer to EUROCAE ED-76A / RTCA DO-200B.

ED-119C/DO-291C:

Integrity of data in the aeronautical data processing chain from data origination process to present data manipulation process.
Encoding: expressed in terms of probability of data loss or alteration (0=perfect, 1=all lost).
Example: essential ICAO Annex 15 0.0001=10e-5.

Also: AMDB section of ED-119C/DO-291C mentions integrity as an extension to ISO 19115. It has the following example: <amdb:dataIntegrity>0.00000001</amdb:dataIntegrity>

Discussions (16 July)

The group decided not to use ISO's extension mechanism.

The group point out that it is not recommended to use numerical values, because the ICAO SARPS do no longer use such numerical values. It requires just that the process ensures the 3 levels (routine, etc.)

It was therefore decided to use the Lineage option.

Browser not supported