change log
- WILSON Scott
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; | 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:
| 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> 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 | 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. 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:
changes were made to integrate the obstacle metadata to 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:
| 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: | 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.