Service Description
asrv.aero
Flight Service
Until this note is removed the documentation is a work in progress, and revisions to the documentation will not be tracked.
Namespace: http://www.asrv.aero/restservices/1.0/flightservice
NB! This namespace only applies to the XML schema defining the XML return data.
Document revisions
Date | Description | Author |
---|---|---|
yyyy-mm-dd | First complete version of the documentation | Ole Nymoen |
- 1. Introduction
- 2. Service overview
- 3. Service operations
- 3.1. GetFlightDataInbound( flightFilter: FlightFilter ) : GetFlightDataInboundResponse
- 3.2. GetBasicFlightDataInbound ( flightFilter: FlightFilter ) : GetBasicFlightDataInboundResponse
- 3.3. GetFlightDataOutbound( flightFilter: FlightFilter ) : GetFlightDataOutboundResponse
- 3.4. GetBasicFlightDataOutbound( flightFilter: FlightFilter ) : GetBasicFlightDataOutboundResponse
- 3.5. GetFlightLegData ( flightFilter: FlightFilter ) : GetFlightLegDataResponse
- 3.6. GetBasicFlightLegData ( flightFilter: FlightFilter ) : GetBasicFlightLegDataResponse
- 3.7. GetTurnaroundData( flightFilter: FlightFilter ) : GetTurnaroundDataResponse
- 3.8. GetBasicTurnaroundData ( flightFilter: FlightFilter ) : GetBasicTurnaroundDataResponse
- 3.9. GetAlerts ( flightFilter: FlightFilter ) : GetAlertsResponse
- 4. Data entities
- 5. XML Usage
- 6. WSDL and XSDs
1. Introduction
1.1. Overview
This service description defines a REST (like) service that can be used to request flight oriented data. All flight related data elements are defined by the Airport Data Dictionary.
The service is designed to be easy to use, and can return data in different formats (HTML, XML, JSON). It is primarily meant as a data source for publicly available services, but availability and usage are the decision of the service provider.
In addition to this service description the service provider must have an implementation description defining the URLs to use and and limitations in the actual implementation.
There are a set of use cases that can be realized using this service, for example:
-
- Get arrival data for one airport, or for several airports if the implementation supports it.
- Get departure data for one airport, or for several airports if the implementation supports it.
- Get turnaround data for one airport, or for several airports if the implementation supports it.
Turnaround data contains one arrival and the corresponding departure at one airport. - Get flight leg data for one airport, or for several airports if the implementation supports it
Flight leg data contains the departure and arrival data for one aircraft movement. For one airport this will be flight legs that arrives or departs from the airport. For implementations with several airports, this will be all flight legs, without duplications, that touches one of the airports.
While the entity definitions stay the same, the data they contain related to one flight will change as time goes by. Initially only schedule data will be available. The data content should then steadily increase as the flight progresses, until it is as complete as the service provider can make it.
1.2. Implementation considerations
Any implementation of this service MUST use the XSD files provided here: WSDL and XSDs
It is up to the service provider which data elements to support, and how much data to return for requests spanning a long time period. To enable this most elements are optional. The reason for a service provider to not support all elements might be business rules related to data distribution, that it doesn't have the information, or that it wants to provide information in other (more restricted) ways.
Any service provider should make available documentation about the actual implementation, including:
-
- the address/URL of the service
- any limitations in the implementation
- the airport(s) supported
- the scope of the data set
- the default values for parameters
- recommended and allowed polling intervals
- any other relevant information.
1.3. Who should implement this service
This service is primarily meant for airports that want to make flight related information available in a "standard" way. It can however also be implemented by other providers of flight related information, for instance airlines and helicopter companies.
1.4. Purpose of this service description
This service description has the following purpose:
-
-
- Describe of service in enough detail for a service provider to implement it.
- Describe the service so that a client (of this service) developer can use it.
- Make available any definition (XSD) files necessary to implement and use the service.
- Make it possible for relevant people to understand the available functionality and then to decide if to implement/use it or not.
-
1.5. Intended readership
-
- IT architects
- Developers
- Business architects
- Interested parties in the aviation community
2. Service overview
TBD
3. Service operations
TBD
3.1. GetFlightDataInbound( flightFilter: FlightFilter ) : GetFlightDataInboundResponse
Returns data about the set of inbound flights that fit the FlightFilter.
Parameters:
filghtFilter: See definition of FlightFilter under Data entities.
Returns:
|
|
3.2. GetBasicFlightDataInbound ( flightFilter: FlightFilter ) : GetBasicFlightDataInboundResponse
Returns basic data (a simplified data set) about the set of inbound flights that fit the FlightFilter.
Parameters:
filghtFilter: See definition of FlightFilter under Data entities.
Returns:
|
3.3. GetFlightDataOutbound( flightFilter: FlightFilter ) : GetFlightDataOutboundResponse
Returns data about the set of outbound flights that fit the FlightFilter.
Parameters:
filghtFilter: See definition of FlightFilter under Data entities.
Returns:
|
3.4. GetBasicFlightDataOutbound( flightFilter: FlightFilter ) : GetBasicFlightDataOutboundResponse
Returns basic data (a simplified data set) about the set of outbound flights that fit the FlightFilter.
Parameters:
filghtFilter: See definition of FlightFilter under Data entities.
Returns:
|
3.5. GetFlightLegData ( flightFilter: FlightFilter ) : GetFlightLegDataResponse
Returns data about the set of flights legs that fit the FlightFilter.
Parameters:
filghtFilter: See definition of FlightFilter under Data entities.
Returns:
|
{2621169E-6A78-4e1f-A68B-471745DECB3D}
3.6. GetBasicFlightLegData ( flightFilter: FlightFilter ) : GetBasicFlightLegDataResponse
Returns basic data (a simplified data set) about the set of flights legs that fit the FlightFilter.
Parameters:
filghtFilter: See definition of FlightFilter under Data entities.
Returns:
|
3.7. GetTurnaroundData( flightFilter: FlightFilter ) : GetTurnaroundDataResponse
Returns data about the set of turnarounds that fit the FlightFilter.
Parameters:
filghtFilter: See definition of FlightFilter under Data entities.
Returns:
|
3.8. GetBasicTurnaroundData ( flightFilter: FlightFilter ) : GetBasicTurnaroundDataResponse
Returns basic data (a simplified data set) about the set of turnarounds that fit the FlightFilter.
Parameters:
filghtFilter: See definition of FlightFilter under Data entities.
Returns:
|
3.9. GetAlerts ( flightFilter: FlightFilter ) : GetAlertsResponse
Returns data about the set of alerts that fit the FlightFilter.
Parameters:
filghtFilter: See definition of FlightFilter under Data entities.
Returns:
|
4. Data entities
4.1. Alert
|
4.2. BasicFlightDataInbound
|
|
4.2.1. Elements that might be added
remark_1 (optional) Description: This field holds public remark for arrival/departure.
remark_2 (optional) Description: This field holds staff remark for arrival/departure.
next_info (optional) Description:
This field holds time of new info. Time is reported by MVT NI. UTC time value follows ISO 8601 format used in XML ’dateTime’ type.
last_delay_code (optional) Description: This field holds code for delay
last_delay_code2 (optional) Description: This field holds code2 for delay
4.3. BasicFlightDataOutbound
|
|
4.3.1. Elements that might be added
checkindesk-data
remark_1 (optional) Description: This field holds public remark for arrival/departure.
remark_2 (optional) Description: This field holds staff remark for arrival/departure.
next_info (optional) Description:
This field holds time of new info. Time is reported by MVT NI. UTC time value follows ISO 8601 format used in XML ’dateTime’ type.
last_delay_code (optional) Description: This field holds code for delay
last_delay_code2 (optional) Description: This field holds code2 for delay
4.4. BasicFlightLegData
|
4.5. BasicTurnaroundData
|
4.6. FlightDataInbound
|
Expanded version of FlightDataInbound
4.7. FlightDataOutbound
|
Expanded version of FlightDataOutbound
4.8. FlightFilter
Describe usage here, definitions below.
|
Include definitions of terms and types here
FlightId |
IATA based identifier for this flight, usually issued long before the flight actually takes place. FlightId is normally the concatenation of OperatingAirlineIATA, FlightNumber and OperationalSuffix. FlightId typically identifies a flight to the majority of systems, but it is not unique across time. It's unique only in conjunction with FlightDepartureDate. Exception: Some airlines use their ICAO code (OperatingAirlineICAO) instead of OperatingAirlineIATA. This might be because they aren't an IATA member or because they just prefer the ICAO code. Regardless, this means that it is allowed to use OperatingAirlineICAO as part of FlightId. FlightId is then defined as the concatenation of AirlineIATAorICAO, FlightNumber and OperationalSuffix. |
4.9. FlightLegData
NB! FlightLegData has information about the departure and the arrival of one flight leg.
|
Expanded version of FlightLegData
4.10. FlightLegIdentifier
|
|
4.11. ResponseStatus
|
|
4.12. TurnaroundData
NB! TurnaroundData has information about the arrival and departure of one aircraft.
Flight leg relevant data must be moved to the arrival/departure part. The arrival/departure parts represent the respective flight legs.
|
Expanded version of TurnaroundData
5. XML Usage
5.1. Nil Values in Schema
For any particular data element, there is an important distinction between the following cases:
(a) the element is missing
(b) the element is present but has a 'nil' attribute assigned to it
In the first case, this means that the sender is supplying no information about the element. This would typically be because no information is available, or because there has been no change in the value of the element. A recipient would not be expected to take any action as a result of this. In particular, it would not be expected to clear any existing value.
In the second case, this means that the sender has explicitly cleared the element. As a result of this, a recipient would typically clear any value that it had previously stored for this element.
The following table shows an example sequence of messages, and the expected actions taken by the data recipient. It should be noted, however, that the action is up to the recipient. The message from the sender is a notification, and not a command for the recipient to take action.
Message contents |
Expected action by recipient |
---|---|
aircraftRegistration element missing |
Does not set or change aircraft registration value |
<aircraftRegistration>ABC123</aircraftRegistration> |
Sets the value to ABC123 |
aircraftRegistration element missing |
Does not change the value |
<aircraftRegistration xs:nil=’true’> |
Clears the aircraftRegistration value |
Note that the sender should not use blank data elements such as <aircraftRegistration/> or <aircraftRegistration></aircraftRegistration> as these may cause validation errors. For example, if the schema specifies a format or a minimum length for an element, then a zero-length element will be invalid. This problem does not occur if using the nil attribute.
Note - Where a field is defined as mandatory in the schema, it must not contain a nil value.
6. WSDL and XSDs