Dataset Description
asrv.aero
Avinor Flight Leg State v 3.0
Namespace: http://www.asrv.aero/dataset/3.0/AvinorFlightLegState/
Document revisions
Date | Description | Author |
---|---|---|
NOT under version control yet |
1. Dataset facts
-
Name: AvinorFlightLegState
-
Availability: Services and data push
-
Security: Depends on availability option
-
Content: Depends on client authorization.
2. Introduction
2.1. Overview
This dataset represents the maximum information Avinor has available regarding a flight leg. The actual content depend on the information Avinor has received and the clients authorization. For flight legs more than a few days into the future it will mostly be schedule data. As actual flight time nears, and as the flight leg progresses, it will be more and more data.
The data elements actually available for a given client will depend on the client's authorization.
All data elements are defined by the Airport Data Dictionary.
The dataset is primarily designed to meet the need of airport partners.
2.2. Implementation considerations
If Avinor doesn't have the data element, or the client doesn't have the authorization to see it the element will be missing from the returned data. No empty elements will be provided. This applies for single data elements and entities.
2.3. Purpose of the dataset description
This dataset description has the following purpose:
-
-
- Make it possible for relevant people at airports, airlines, handlers and other aviation partners to understand the available data and then to decide if to use it or not.
- Describe the dataset so that a developer can use it.
- Make available the XSD files necessary.
-
2.4. Intended readership
-
- IT architects
- Developers
- Business architects
- Interested parties in the aviation community
3. Data entities
3.1. Overview
The figure below shows the all of the entities in AvinorFlightLegState. Details about each entity is on the relevant page.
3.2. AircraftData
Information about the aircraft that flew this flight leg.
3.3. ArrivalData
|
|
3.4. BaggageData
Baggage information related to the flight leg.
NB! Information about transfer baggage are placed in PassengerData.
|
|
3.5. CargoData
Information about the cargo of this flight leg.
|
|
3.6. ChargeBorderCrossingData
Entity containing any data related to crossing of charging areas. This would typically be when the aircraft entered a new FIR.
|
|
3.7. CheckInData
Entity containing any check-in data connected to this flight leg.
|
|
3.8. CodeshareData
Entity containing any codeshare data connected to this flight leg.
|
|
3.9. DeIceData
Entity containing any de-ice data connected to this flight leg.
|
|
3.10. DelayData
Entity containing any delay data connected to this flight leg, departure or arrival.
|
|
3.11. DepartureData
|
|
3.12. DisplayData
DisplayData indicates if the information in the corresponding FlightLegStateData should be displayed or not. This is primarily for monitors, but should also be respected for other clients. It might mean that the data also should be removed from services, but that decision should be on a per service basis.
NB! FlightLegStateMetadata.ClassificationLevel MUST be respected. Only flight legs marked as "PUBLIC" should ever be displayed, or made available through services, to the general public.
The following matrix shows the possible combinations of ClassificationLevel and PublicDisplayStatus.
ClassificationLevel | PublicDisplayStatus | Result |
---|---|---|
1 - «PUBLIC» |
'0' |
Should not be shown/made available without authorization. |
1 - «PUBLIC» |
'1' | Can be shown/made available everywhere |
1 - «PUBLIC» | '2' | Should only be visible at the departure airport |
1 - «PUBLIC» | '3' | Should only be visible at the arrival airport |
2 - «NON-PUBLIC» | All values | Should not be shown/made available without authorization. |
3 - «RESTRICTED» |
All values | Should not be shown/made available without authorization. |
Information related to how the flight leg data should be displayed.
|
|
3.13. DiversionFromData
Entity containing information about the airport this flight leg diverted from.
The first DiversionFromData entity is always the original arrival airport with corresponding timestamps. If an aircraft is diverted multiple times there will be multiple instances of DiversionFromData.
See Specification: Rerouting of flights and flight legs for more information on how diversions should be handled.
|
|
3.14. FlightLegStateData
Main entity that contains all the elements that make up the state of a flight leg.
The figure below shows the entities that are directly associated with FlightLegStateData.
|
|
3.15. FlightLegStateMetadata
FlightLegStateMetadata give extra information about FlightLegStateData, and not about the flight leg.
|
|
3.16. GateData
Entity containing any gate data connected to this flight leg.
|
3.17. HandlerData
Entity containing any handler data connected to this flight leg, departure or arrival.
|
3.18. LinkedArrivalData
|
|
3.19. LinkedDepartureData
|
|
3.20. LoadData
Entity containing flight segment related load data for single or multi leg flights. See Specification: IATA - Calculating PAX numbers from Load data.
Load data is segment oriented data. A flight segment is what you can buy a ticket for.
- For a single leg flight, A to B, the flight segment is AB.
- For a multi leg flight, A to B to C to D the following flight segments exist: AB, AC, AD, BC, BD, CD
Load data are submitted at each departure airport for the remaining segments.
|
|
3.21. PassengerData
Passenger data, including data about transfers from other (previous) flights and transfers to other (later) flights.
|
|
3.22. RemarkData
Entity containing any remarks connected to this flight leg.
|
|
MAOS Code | MAOS Description | Direction | Data Definition (max 16 characters) | Explanation |
---|---|---|---|---|
PG | PublicGateRemark | D |
PublicGate |
The remark shall be shown on all gate screens. Typical use is telling passengers on row 16-32 that is time to board the plane. |
PC | PublicCheckinRemark | D |
PublicCheckin |
The remark shall be shown on all check-in screens. Typical use is letting pax know that check-in area has been changed. |
PD | PublicDepartureRemark | D |
PublicDeparture |
The remark shall be shown on all screens where the departure flight is shown, both for pax and employees. |
SD | StaffDepartureRemark | D |
StaffDeparture |
The remark shall only be shown to employees in the client. There is also a separate field for this in the xml-feeds. This remark is not to be displayed on any pax screens. |
PA | PublicArrivalRemark | A |
PublicArrival |
The remark shall be shown on all screens where the arrival flight is shown, both for pax and employees. |
SA | StaffArrivalRemark | A |
StaffArrvial |
The remark shall only be shown to employees in the client. There is also a separate field for this in the xml-feeds. This remark is not to be displayed on any pax screens. |
3.23. TouchAndGoData
Entity containing any data related to crossing of touch and gos.
|
|
3.24. TransferData
Entity containing number of passengers and baggage that
- are expected to be transferred from an arriving flight to this flight leg.
- are expected to be transferred from this flight leg to departing flights.
|
|