o
If the code is identified as a 4-letters code, the existence of the code is checked in the airport table under the ICAO code field.
o
If the code is identified as different from a 4-letters code then the existence of the code is checked in the airport table under the IATA code field.
o
If the code is not identified, then the flight is marked as inconsistent.
.
A checking on the aircraft code:
o
If the aircraft code is not identified in the aircraft equivalent table then an exception is raised and the flight is marked as inconsistent.
o
The creation of the FLUID number.
Import of ETMS headers
The import of ETMS headers consists of extracting data from the ETMS Flight.txt file and to load them into FLIGHT_TEMP table (Table 18) as for the import of AMOC headers. The difference is that the checking of the airport code refers to an airport table designed specifically for ETMS data (Phase 2 Paragraph 4).
2.2. Update of the maximum stop time
For each source, the arrival time of all flights is updated with the departure time plus 950 minutes.
2.3. Flight legs importing procedure
Import of AMOC flight legs
The import of AMOC flight legs consists of extracting data from the AMOC Flight.txt file and to match the legs with the headers. The matching is based on the callsign, the event date and the source. If no matching flight header is found or if more than one is found then the legs are marked as inconsistent. The data extracted are shown in Table 19.
Import of ETMS flight legs
The import of ETMS flight legs consists of extracting data from the ETMS Flight_chord.txt file and to match the legs with the headers as for AMOC. An additional operation is the conversion of the data in the units used in AMOC. The data extracted are shown in Table
19.
2.4. Schedule data file importing procedure
The import of the schedule data headers is similar to AMOC and ETMS procedure at the exception of the calculation of the callsign. In Back Aviation the callsign needs to be concatenated using the airline code and the flight number. The airline code is converted and checked using the airline table (Phase 1 Paragraph 7). Time expressed as local time is converted into GMT time.
The import of the schedule data flight legs requires first their creation. This is done on the basis of either existing flights or on the use of aircraft profiles associated with route network knowledge. This creation is described in Phase 2 Paragraph 9.
3
.
T
h
e
g
l
o
b
a
l
t
i
m
e
z
o
n
e
c
o
n
v
e
r
t
e
r
The system explained in Phase1 Paragraph 5 was made compatible with the migration towards Oracle 9i without main changes. The content of the table is shown in Table 20.
Table 20: Table TIME_ZONE_DATA.
Col # Column Name Data Type Data Description
1 TIME_ZONE VARCHAR2(10) Unique code given to each location
2 CTY_NAME VARCHAR2(50) Name of the country
3 REGION VARCHAR2(60) Name of the region
4 CITY_LIST VARCHAR2(60) Major cities in the region
5 STD_BIAS NUMBER Standard offset in GMT
6 DST_BIAS NUMBER Daylight saving time or “summer time” offset to add or retrieve
7 DST_START_PATTERN VARCHAR2(16) Daylight saving time starting date
8 DST_STOP_PATTERN VARCHAR2(16) Daylight saving time end date
