Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Note for reviewers

The coding part of this scenario was documented on Google Drive in draft AIXM 5.1(.1) Digital NOTAM Specification - Part 2 : Coding Rules -

This scenario has been transferred to this Conf page and will be updated accordingly.

Definition

The temporary outage of structure lighting associated with an obstacle/obstruction.

Notes:

  • this scenario covers the outage of lighting associated with existing obstacles/obstructions that are lighted;
  • this scenario covers both airport and en-route obstacles;
  • this scenario does not cover other status changes to existing obstacles/obstructions.

Event data

The following diagram identifies the information items that are usually provided by a data originator for the temporary outage of obstacle lighting.


The table below provides more details about each information item contained in the diagram. It also provides the mapping of each information item within the AIXM 5.1 structure. The name of the variable (first column) is recommended for use as label of the data field in human-machine interfaces (HMI).

Data item

value

AIXM mapping

obstacle identification

An alphanumerical designator by which the obstacle is identified in the national obstacle database

VerticalStructure/VerticalStructurePart.designator

obstacle type

A type of vertical structure. This data item is used (together with other information) in order to search for the VerticalStructure that is concerned.

VerticalStructure.type and VerticalStructure/VerticalStructurePart.type with this list of values CodeVerticalStructureType.

position

The latitude, longitude and possibly the horizontal reference datum associated with the obstacle position. This data item is used (together with other information) in order to search for the VerticalStructure that is concerned.

VerticalStructure/VerticalStructurePart/ElevatedPoint

lights status

The status of the obstacle warning lights.

VerticalStructure/..VerticalStructureLightingStatus.status 

with the following list of values CodeStatusOperationsType

schedule

A schedule might be provided, in case the obstacle is only active according to a regular timetable, within the period between the start of life and the end of life.

VerticalStructure/VerticalStructurePart/Timesheet/...according to the rules for {{Schedules}}

start time

The effective date & time when the obstacle starts to exist. This might be further detailed in a "schedule".

VerticalStructure/VerticalStructureTimeSlice.featureLifetime/beginPosition, VerticalStructure/VerticalStructureTimeSlice/validTime/timePosition, Event/EventTimeSlice.validTime/timePosition and Event/EventTimeSlice.featureLifetime/beginPosition

end time

The end date & time when the obstacle ceases to exist

VerticalStructure/VerticalStructureTimeSlice.featureLifetime/endPosition and Event/EventTimeSlice.featureLifetime/endPosition also applying the rules for {{Events with estimated end time}}

note

A free text note that provides further details about the obstacle, such as the reason for which it exists, reduced height at certain times, etc.

VerticalStructure.annotation according to the rules for encoding annotations

Notes:


  • It is recommended that data input applications allow the operator to visualise graphically the position and extent of the obstacle, overlaid on an airport map or on an FIR map, as appropriate. If a schedule is used, the graphical interface should also have a "time slider" that allows the operator to see when the obstacle is actually effective.


Assumptions for baseline data

  • It is assumed that the obstacle/obstruction data is available in a national obstacle database and can be processed in the form of a VerticleStructure BASELINE TimeSlice and VerticalStructurePart BASELINE TimeSlice, which contains a minimum of designator, position, elevation, and height.

Data encoding rules

The data encoding rules provided in this section shall be followed in order to ensure the harmonisation of the digital encodings provided by different sources. The compliance with some of these encoding rules can be checked with automatic data validation rules. When this is the case, the number of the encoding rule is mentioned in the data validation rule.

Identifier

Data encoding rule

ER-01

The temporary outage of the obstacle/obstruction light shall be encoded as:

  • a new Event, for which PERMDELTA and subsequent BASELINE TimeSlice shall be created; and
  • a TimeSlice of type TEMPDELTA for the affected VerticalStructure feature, for which the "event:theEvent" property points to the Event instance created above.

ER-02

- if baseline data has one or more light elements, then set their operational status to u/s;

otherwise create an ad-hoc light element, no position, put on únserviceable'

ER-03

If the obstacle lighting system is limited to a discrete schedule within the overall time period between the “start time” and the “end time”, then it shall be encoded using as many as necessary timeInterval/Timesheet properties for the VerticalStructueLightingStatus of the VerticalStructure TEMPDELTA Timeslice. See the rules for Event Schedules.

ER-04

According to the AIXM Temporality Concept, the VerticalStructureLightingStatus elements included in TEMPDELTA completely replace all BASELINE VerticalStructureLightingStatus information, during the time of applicability of TEMPDELTA. Therefore, if the modified operational status only concerns certain times, the other times when the obstacle lighting system remains in the same status as in the BASELINE data shall be explicitly included in the TEMPDELTA. 

  • No labels