Basic properties for obstacles

A definition of "Area of coverage" can be found in RTCA/EUROCAE DO-276/ED-98 :

• "Area of coverage is a descriptor used to identify the boundary of the obstacle data."

Also a description is provided: "This should be used to help the user identify in general terms the area under consideration" and a data capture rule : "The area coverage shall be identified which describes the geographical extent of the data set provided".

Description from the EUROCONTROL TOD Manual : "A description of the geographical area for which the data set provides coverage. This should be provided as a series of co-ordinates describing a bounding box. This metadata should relate to the entire data set and, if more than one area is provided within the  data  set,  for  each  area provided.  For  example,  a  single  data  set  may  be  provided  for  a TMA comprising several aerodromes, each of which provides Area 2, Area 3 and Area 4 data."

In some particular cases (such as for a mobile or temporary obstacle) it might be necessary to provide the information about the obstacle owner, in order to enable the airspace users to contact the owner and find out if the obstacle is present at a certain moment in time. For that purpose, the contact details of the obstacle owner can be mapped to a Note associated with the VerticalStructure.

Description from the TOD Manual : "an indication of the entity that provides the data set. Can be at the level of the data set or at the level of each area of the data set."

Description from the TOD Manual : "Each obstacle that has been collected should be allocated a unique identifier which will remain the primary means of identifying the obstacle throughout its life, i.e. it should not be changed as a result of a resurvey or reissue of a data set. The identifier should be independent of any data set within which it is contained, such that if it were to appear in more than one area or delivered data set, it should retain the same identifier."

DO-276/ED-98 has two attributes:

• Obstacle Idnumber, defined as "a special unique identifier permanently assigned to a feature instance by the data provider." This maps to the ICAO PANS-AIM requirement for "obstacle identifier".

• Obstacle Identifier, defined as "the name / identifier of the obstacle". This is further detailed in a note: "The obstacle identifier is not necessarily unique; it can be the name of the obstacle (e.g. Control Tower)." The AIXM model supports the encoding of an obstacle name as VerticalStructure.name. This will be further discussed in the coding guidelines.
  
  

DO-276/ED-98 defines the obstacle type as "a description of the recorded obstacle, e.g., tower, building, tree, power lines, windmill farms, or cable cars."

Description from the TOD Manual : "An indication of the type of obstacle recorded. This should be assessed against a generic set of obstacle types which includes types such as tree, building, wind-turbine, etc. This information is linked to the obstacles recorded and should, therefore, be provided at this level (data level)."

in AIXM, a type can also be encoded for each part, in the case of complex structures (such as a power line with poles, etc.) using the VerticalStructurePart.type.

Additional information is provided through the Temporality Concept of AIXM. A new TimeSlice is provided and becomes effective when there is changed data about the obstacle.

DO-276/ED-98 requires the "Feature Life Time" - defined as "period during which feature exist", which is further described as "start and end of life of the feature, indicating the date and time at which the feature starts and ceases to exist."

DO-276/ED-98 also requires 'Revision Date and Time' which is defined as "the revision date and time are information about the origination or modification date and time of the data."  in the the TOD Manual this appears as "Date and time stamp", which "should be applied at the data level and the date and time at which the data set was created or last modified should also be provided."

RTCA DO-276 /ED-98 also defines the "status" of an obstacle, which for which a data capturing rule is provided: "when an obstacle is being built and surveyed in the field, an indication “planned,” “under construction” or “completed” shall be provided".

The TOD manual the "operations" attribute was used to reflect the current status of the obstacle e.g. to indicate that the obstacle is:

• Planned;
• Under construction;
• Completed;
• Demolition planned;
• In demolition.

For obstacles that exist according to a repetitive schedule, the effective time can be coded using Timesheet associated with the VerticalStructurePart.

If the obstacle itself is temporary, then the time during which it actually exists can be coded using the validTime property of the VerticalStructure (see the AIXM Temporality Concept)

In DO-276/ED-98 'effectivity' is divided into:

• Validity - defined as "the validity period of a feature state", which is further described as "dates and times at which the data contained in the feature state starts or ceases to be effective." In AIXM, this corresponds to the VerticalStructure.validTime.
•  Interpretation - "Interpretation information defines how the feature state is to be interpreted. This enables explicit communication of the temporal characteristics of the provided features."In AIXM, this corresponds to the VerticalStructureTimeSlice.interpretation property ('BASELINE, TEMPDELTA, SNAPSHOT').