3.2.1... List of participants by discipline / List of participants by discipline Update
3.2.2... List of teams / List of teams update
3.2.8... Discipline Configuration
3.2.9... Event Unit Weather Conditions
6.2.. ODF Data Types and Formats
6.2.1... Rules for rounding numbers
6.2.3... Rules for measures conversion
This document includes the ODF Ski Jumping Data Dictionary. This document refines the messages described in the ODF General Messages Interface Document specifically for Ski Jumping, as well as defines the codes used in these messages.
The objective of this document is to provide a complete and formal definition of the ODF Ski Jumping Data Dictionary, with the intention that the information message producer and the message consumer can successfully interchange the information as the Ski Jumping competition is run.
The main audience of this document is the IOC as the ODF promoter, ODF users such as the World News Press Agencies, Rights Holding Broadcasters and International Sports Federations.
The following abbreviations are used in this document
Acronym |
Description |
IF or International Federation |
The international governing body of an Olympic Sport as recognized by the IOC |
IOC |
International Olympic Committee |
IPC |
International Paralympic Committee |
NOC |
National Olympic Committee recognized as such by the IOC |
NPC |
National Paralympic Committee as recognized by the IPC |
ODF |
Olympic Data Feed |
ODF Light |
It is a type of ODF message that includes extensions to standard ODF messages in order to resolve references between messages and common codes. These extensions facilitate the message processing for ODF customers |
ODF-PiT |
Olympic Data Feed Point in Time, messages that are generated at certain point during competition |
ODF-RT |
Olympic Data Feed Real Time, messages that are generated when available |
OPNS |
Olympic and Paralympic News Service |
Results System Codes, determine uniquely one unit of the competition, specifying the discipline, gender, event, phase and unit. |
|
Sport |
is administered by an international federation and can be composed of one or more disciplines |
WNPA |
World News Press Agencies |
Document Reference |
Document Title |
Document Description |
ODF/INT001 |
ODF Message Transmission Document |
This document describes the technical standards to be used to transfer ODF messages between the message generators and the final ODF users |
ODF/COD001 |
ODF Common Codes Document |
This document describes the ODF codes used across the rest of the ODF documents |
ODF/INT004 |
ODF General Messages Interface Document |
This document describes the ODF general messages |
The objective of this document is to focus on the formal definition of the ODF Ski Jumping Data Dictionary.
In the following chapters, for each ODF message the general description, header values, triggers and frequency, structure, values and sort of the message will be defined.
The following table is a full list of all ODF messages and describes the list of messages used in this sport.
• The column “Message type” indicates the DocumentType that identifies a message
• The column “Message name” is the message name identified by the message type
• The column “Feed” identifies the message feed (PiT for Point in Time messages, RT for Real Time messages and PDF for PDF messages)
• The column “Message extended in this document” indicates whether a particular message has extended definition in regards to those that are general for all sports. If one message has extended definition, it should be considered both, the extensions as well as the general rules for one message that is used in the case of the sport. However, if one particular message is not extended, then it should follow the general definition rules.
Message Name |
Feed |
Message extended |
|
DT_SCHEDULE |
Competition schedule |
PiT |
|
DT_SCHEDULE_UPDATE |
Competition schedule update |
PiT |
|
List of participants by discipline / List of participants by discipline Update |
|||
DT_MEDALS |
Medal standings |
PiT |
|
DT_MEDALLISTS_DAY |
Medallists of the day |
PiT |
|
DT_GLOBAL_GM |
Global good morning |
PiT |
|
DT_GLOBAL_GN |
Global good night |
PiT |
|
DT_MEDALLISTS_DISCIPLINE |
Medallists by discipline |
PiT |
|
DT_COMMUNICATION |
Official Communication |
PiT |
|
DT_GM |
Discipline/venue good morning |
PiT |
|
DT_GN |
Discipline/venue good night |
PiT |
|
DT_SERIAL |
List of Current PiT Serial |
PiT |
|
DT_RT_KA |
RT Discipline/Venue keep alive |
RT |
|
DT_PDF |
PDF Message |
|
|
DT_PDF_GM |
PDF Discipline/Venue good morning |
|
|
DT_PDF_GN |
PDF Discipline/Venue good night |
|
|
DT_PDF_SERIAL |
List of Current PDF Serial |
|
|
DT_RT_GM |
RT Discipline/venue good morning |
RT |
|
DT_RT_GN |
RT Discipline/venue good night |
RT |
|
A participant is considered as an individual competitor (type athlete, participating or not in the current games) or as an official in one or several disciplines or as a competitor being part of a team (team member).
Although the participant participates in more than one event or more than one discipline, this message just contains all the information for the discipline of the message, although listing the information of all the events for that discipline.
This message includes historical athletes that do not participate in the current competition. Historical athletes will not be registered to any event.
It is important to point out that all the sport messages that make references to athletes (start list, event unit results, etc.) will always match the athlete ID with the athlete ID as it is being sent in the List of athletes by discipline message. The historical athletes will be used to match historical athlete information as it is in the records message when sending the previous record information and this previous record was an historical record not being broken in the current competition.
This message also includes the historical team members of the historical teams’ messages. It could happen these historical athletes would appear in this message just for this reason (being part of historical teams).
List of participants by discipline (DT_PARTIC) is a bulk message, provided for each discipline. It is a complete participant information message for one particular discipline. The arrival of this message resets all the previous participants’ information for one particular discipline. This message can include a list of current athletes, officials, coaches, guides, technical officials, Reserves and historical athletes.
List of participants by discipline update (DT_PARTIC_UPDATE) is an update message. It is not a complete list of participants’ information by discipline message, only the participant data being modified, i.e. if some data of one participant changes, the element Participant for it with all its children and attributes must mbe sent.
The key of the information updated consists of the following attribute: Participant @Code. Therefore, any new or updated Participant Discipline-Event will be identified by all these attributes.
The following table describes the ODF header attributes
Attribute |
Value |
Comment |
DocumentCode |
DD0000000 |
DD is defined according to CC @Discipline |
DocumentType |
DT_PARTIC / DT_PARTIC_UPDATE |
List of participants by discipline message |
Version |
1..V |
Version number associated to the message’s content. Ascendant number |
FeedFlag |
“P”-Production “T”-Test |
Test message or production message. |
Date |
Date |
Date when the message is generated, expressed in the local time zone where the message was produced. |
Time |
MillisTime |
Time up to milliseconds when the message is generated, expressed in the local time zone where the message was produced. |
LogicalDate |
Date |
Logical Date of events that extends until next day. If an event unit continues after midnight (24:00), all messages produced will be considered as happening at the logical date on which the event unit began (e.g. for a session which began at 21:00 on Aug 2 and ended at 1:20 on Aug 3, the output will be dated Aug 2).
The end of the logical day is defined by default at 03:00 a.m.
For messages corrections, like invalidating medals or Records, it will be the LogicalDate of the correction.
Logical Date is expressed in the local time zone where the message was produced |
Serial |
Numeric |
Sequence number for ODF-PiT messages.
Serial starts with 1 each day session at every different venue.
In the case of RT transmission, this attribute contains the last PiT message Serial number in order to ensure that RT information is processed over the last PiT information |
Venue |
Venue where the message is generated. |
The DT_PARTIC message is sent as a bulk message one month before the Games.
It is sent several times up to the date from what only DT_PARTIC_UPDATE messages are sent.
The DT_PARTIC_UPDATE message is triggered when there is a modification in a DT_PARTIC bulk message sent before.
Following table defines the structure of the message.
Level 1 |
Level 2 |
Level 3 |
Level 4 |
Level 5 |
Competition |
|
|
|
|
|
Code |
|
|
|
|
Participant (1,N) |
|
|
|
|
|
Code |
|
|
|
|
Parent |
|
|
|
|
Status |
|
|
|
|
GivenName |
|
|
|
|
FamilyName |
|
|
|
|
PrintName |
|
|
|
|
PrintInitialName |
|
|
|
|
TVName |
|
|
|
|
TVInitialName |
|
|
|
|
Gender |
|
|
|
|
Organisation |
|
|
|
|
BirthDate |
|
|
|
|
Height |
|
|
|
|
Weight |
|
|
|
|
PlaceofBirth |
|
|
|
|
CountryofBirth |
|
|
|
|
PlaceofResidence |
|
|
|
|
CountryofResidence |
|
|
|
|
Nationality |
|
|
|
|
MainFunctionId |
|
|
|
|
Current |
|
|
|
|
OlympicSolidarity |
|
|
|
|
ModificationIndicator |
|
|
|
|
Discipline |
|
|
|
|
|
Code |
|
|
|
|
InternationalFederationId |
|
|
|
|
RegisteredEvent (0,N) |
|
|
|
|
|
Gender |
|
|
|
|
Event |
|
|
OfficialFunction (0,N) |
|
|
|
|
|
FunctionId |
|
Competition
Attribute |
M/O |
Value |
Comments |
Code |
M |
Unique ID for competition |
Participant
Attribute |
M/O |
Value |
Comments |
Code |
M |
S(20) with no leading zeroes |
Participant’s ID.
It identifies an athlete or an official and the holding participant’s valid information for one particular period of time.
It is used to link other messages to the participant’s information.
Participant’s information (example @Organisation) will not be the latest for the athlete/official, unless the @Code attribute is the same as the @Parent attribute. However, this information could be the one being valid in the particular moment of a start list, event unit results, etc.
When the participant is an historical one, then this ID will start with “A” when it is an Athlete, “C” when Coach and “O” when Official. |
Parent |
M |
S(20) with no leading zeroes |
Participant’s parent ID, which is used to link to the latest valid information for one participant. @Parent attribute should be linked to the latest participant‘s information, by retrieving that Athlete/Official whose @Code attribute is the same as @Parent.
The participant containing @Code attribute being the same as the @Parent attribute will be the one with the latest information for the participant. The @Parent attribute will only be different from @Code in the case that critial personal information has changed from previous competitions. The typical examples are Organisation (for change of country) or Name (particularly for women changing their name at marriage). Further to be clear, @Parent and @Code can only be different if Current = "false". |
Status |
O |
Participant’s accreditation status this atribute is Mandatory in the case of @Current=”true” and it is optional in the case that @Current=”false”.
To delete a participant, a specific value of the Status attribute is used. |
|
GivenName |
O |
S(25) |
Given name in WNPA format (mixed case) |
FamilyName |
M |
S(25) |
Family name in WNPA format (mixed case) |
PrintName |
M |
S(35) |
Print name (family name in upper case + given name in mixed case) |
PrintInitialName |
M |
S(18) |
Print Initial name (for the given name it is sent just the initial, without dot) |
TVName |
M |
S(35) |
TV name |
TVInitialName |
M |
S(18) |
TV initial name |
Gender |
M |
Participant’s gender |
|
Organisation |
M |
Organisation ID |
|
BirthDate |
O |
YYYYMMDD |
Date of birth. This information could be not known at the very beginning, but it will be completed for all participants after successive updates |
Height |
O |
N(3) 999 |
Height in centimetres. It will be included if this information is available. This information is not needed in the case of officials/referees. |
Weight |
O |
N(3) 999 |
Weight in kilograms. It will be included if this information is available. This information is not needed in the case of officials/referees. |
PlaceofBirth |
O |
S(75) |
Place of Birth |
CountryofBirth |
O |
Country ID of Birth |
|
PlaceofResidence |
O |
S(75) |
Place of Residence |
CountryofResidence |
O |
Country ID of Residence |
|
Nationality |
O |
Participant’s nationality.
Although this attribute is optional, in very exceptional situations it will not be known, and for this reason not ready to be sent. |
|
MainFunctionId |
O |
Main function In the Case of Current=”true” this attribute is Mandatory. |
|
Current |
M |
boolean |
It defines if a participant is participating in the games (true) or is a Historical participant (false). |
OlympicSolidarity |
O |
Y or N |
Flag indicating if the participant participates in the Olympic Movement program. |
ModificationIndicator |
M |
N, U |
Attribute is mandatory in the DT_PARTIC_UPDATE message only
N-New participant (in the case that this information comes as a late entry) U-Update participant
If ModificationIndicator=’N’, then include new participant to the previous bulk-loaded list of participants
If ModificationIndicator=’U’, then update the participant to the previous bulk-loaded list of participants
To delete a participant, a specific value of the Status attribute is used. |
Participant /Discipline
Although any participating athlete will be assigned at least one discipline, it could be more. Any accredited official will be assigned at least one discipline, but it could be more. If an athlete or official is assigned to more than one discipline, it will be included in the participant message of both disciplines.
Attribute |
M/O |
Value |
Comments |
Code |
M |
It is the discipline code used to fill the OdfBody @DocumentCode attribute. |
|
InternationalFederationId |
M |
S(16) |
Competitor’s federation number for Ski Jumping |
Participant /Discipline /RegisteredEvent
Any accredited athlete will be assigned to one or more events. There is one exception: in some sports, substitutes may be accredited without any associated event.
Historical athletes are not register to any event.
Attribute |
M/O |
Value |
Comments |
Gender |
M |
Discipline Gender Code |
|
Event |
M |
Event ID |
Participant /OfficialFunction
Send if the official has optional functions. Do not send, otherwise.
Attribute |
M/O |
Value |
Comments |
FunctionId |
M |
Additional officials’ function code |
The message is sorted by Participant @Code
DT_PARTIC_TEAMS contains the list of teams related to the current competition.
A team is a type of competitor, being a group of two or more individual athletes participating together in one event. Pairs (tennis, figure skating, etc.) are also defined as team of two competitors. One team participates in one event of one discipline. When one team participates in multiple events, there will be one team for each event for the same group. Also when the same organisation participates in the same event twice, there will different teams.
A historical team is defined as a group of athletes (team members) competing in the past in a competition event for an organisation. The historical team members appearing in this message will be listed in the list of historical athletes’ messages. The list of historical teams just associates historical team members with the corresponding historical teams. Historical teams will not be registered to any event.
For equestrian one athlete and one horse are not considered a team, the horse is an attribute of the athlete.
List of teams (DT_PARTIC_TEAMS) is a bulk message by discipline. The list is always complete. The arrival of this message resets all the previous participant teams’ information for that discipline. It is assumed that all teams appearing in this list are valid, in the meaning that they are participating or they could participate in one event.
List of teams update (DT_PARTIC_TEAMS_UPDATE) is an update message. It is not a complete list of teams’ information message. It only contains the team data being modified.
The key of the information updated consists of the following attribute: Team @Code. Therefore, any new or updated Team Discipline-Event will be identified by all these attributes.
The following table describes the ODF header attributes
Attribute |
Value |
Comment |
DocumentCode |
DD0000000 |
DD is defined according to CC @Discipline |
DocumentType |
DT_PARTIC_TEAMS_UPDATE / DT_PARTIC_TEAMS |
List of participant teams message |
Version |
1..V |
Version number associated to the message’s content. Ascendant number |
FeedFlag |
“P”-Production “T”-Test |
Test message or production message. |
Date |
Date |
Date when the message is generated, expressed in the local time zone where the message was produced. |
Time |
MillisTime |
Time up to milliseconds when the message is generated, expressed in the local time zone where the message was produced. |
LogicalDate |
Date |
Logical Date of events that extends until next day. If an event unit continues after midnight (24:00), all messages produced will be considered as happening at the logical date on which the event unit began (e.g. for a session which began at 21:00 on Aug 2 and ended at 1:20 on Aug 3, the output will be dated Aug 2).
The end of the logical day is defined by default at 03:00 a.m.
For messages corrections, like invalidating medals or Records, it will be the LogicalDate of the correction.
Logical Date is expressed in the local time zone where the message was produced |
Serial |
Numeric |
Sequence number for ODF-PiT messages.
Serial starts with 1 each day session at every different venue.
In the case of RT transmission, this attribute contains the last PiT message Serial number in order to ensure that RT information is processed over the last PiT information |
Venue |
Venue where the message is generated. |
The DT_PARTIC_TEAMS message is sent as a bulk message one month before the Games.
It is sent several times up to the date from what only DT_PARTIC_TEAMS_UPDATE messages are sent.
The DT_PARTIC_TEAMS_UPDATE message is triggered when there is a modification in a DT_PARTIC_TEAMS bulk message sent before.
Following table defines the structure of the message.
Level 1 |
Level 2 |
Level 3 |
Level 4 |
Level 5 |
Competition |
|
|
|
|
|
Code |
|
|
|
|
Team (1,N) |
|
|
|
|
|
Code |
|
|
|
|
Organisation |
|
|
|
|
Number |
|
|
|
|
Name |
|
|
|
|
Gender |
|
|
|
|
Current |
|
|
|
|
ModificationIndicator |
|
|
|
|
Composition (0,1) |
|
|
|
|
|
Athlete (1,N) |
|
|
|
|
|
Code |
|
|
|
|
Order |
|
|
Discipline (0,1) |
|
|
|
|
|
Code |
|
|
|
|
InternationalFederationId |
|
|
|
|
RegisteredEvent (0,1) |
|
|
|
|
|
Event |
|
|
|
|
Gender |
|
|
|
|
Bib |
Competition
Attribute |
M/O |
Value |
Comments |
Code |
M |
Unique ID for competition |
Team
Attribute |
M/O |
Value |
Comments |
Code |
M |
S(20) with no leading zeroes |
Team’s ID (example SJM490ESP01) |
Organisation |
M |
Team organisation’s ID |
|
Number |
M |
N(2) |
Team’s number. In the case there is not more than one team for one organisation participating in one event, it will be 1. |
Name |
O |
S(73) |
Team’s name.
It will apply to some of the disciplines. If there is not any special rule for that discipline, send the Description of the code CC@Organisation. It is Optional in the case of List of Team Update when the @ ModificationIndicator=D |
Gender |
M |
Discipline Gender Code of the Team |
|
Current |
M |
boolean |
It defines if a team is participating in the games (true) or it is a Historical team (false) |
ModificationIndicator |
M |
N, U, D |
Attribute is mandatory in the DT_PARTIC_TEAMS_UPDATE message only
N-New team (in the case that this information comes as a late entry) U-Update team D-Delete team
If ModificationIndicator=’N’, then include new team to the previous bulk-loaded list of teams
If ModificationIndicator=’U’, then update the team to the previous bulk-loaded list of teams
If ModificationIndicator=’D’, then delete the team to the previous bulk-loaded list of teams |
Team /Composition /Athlete
In the case of current teams the number of athletes is 2 or more.
Attribute |
M/O |
Value |
Comments |
Code |
M |
S(20) with no leading zeroes |
Athlete’s ID of the listed team’s member.
Therefore, he/she makes part of the team’s composition. |
Order |
O |
Numeric |
Team member order |
Team /Discipline
Each team is assigned just to one discipline.
Attribute |
M/O |
Value |
Comments |
Code |
M |
It must be the discipline code used to fill the OdfBody @DocumentCode attribute |
|
InternationalFederationId |
M |
S(16) |
Federation number for the corresponding discipline (include if the discipline assigns international federation codes to teams) |
Team /Discipline /RegisteredEvent
Each team is assigned at least to one event, except for a historical team, which will not be registered to any event.
Attribute |
M/O |
Value |
Comments |
Event |
M |
Event ID |
|
Gender |
M |
Discipline Gender Code |
|
Bib |
O |
N(3) 990 |
Team bib number to be sent when available |
The message is sorted by Team @Code.
The Start List is a message containing the list of competitors for one particular event unit (individual or team event unit).
The Start List is a mandatory message for all disciplines.
Each ODF Sport Data Dictionary will include the mandatory attributes /elements of this message and redefine the optional ones.
The following table describes the ODF header attributes
Attribute |
Value |
Comment |
DocumentCode |
DDGEEEPUU |
The DocumentCode attribute in the ODF header will be sent according to the ODF Common Codes document (header values sheet). |
DocumentType |
DT_START_LIST |
Start List message |
Version |
1..V |
Version number associated to the message’s content. Ascendant number |
FeedFlag |
“P”-Production “T”-Test |
Test message or production message. |
Date |
Date |
Date when the message is generated, expressed in the local time zone where the message was produced. |
Time |
MillisTime |
Time up to milliseconds when the message is generated, expressed in the local time zone where the message was produced. |
LogicalDate |
Date |
Logical Date of events that extends until next day. If an event unit continues after midnight (24:00), all messages produced will be considered as happening at the logical date on which the event unit began (e.g. for a session which began at 21:00 on Aug 2 and ended at 1:20 on Aug 3, the output will be dated Aug 2).
The end of the logical day is defined by default at 03:00 a.m.
For messages corrections, like invalidating medals or Records, it will be the LogicalDate of the correction.
Logical Date is expressed in the local time zone where the message was produced |
Venue |
Venue where the message is generated. |
|
Serial |
Numeric |
Sequence number for ODF-PiT messages.
Serial starts with 1 each day session at every different venue.
In the case of RT transmission, this attribute contains the last PiT message Serial number in order to ensure that RT information is processed over the last PiT information |
The general rule is that this message is sent as soon as some of the information arriving in this message and associated to the event unit (PhaseInfos, UnitInfos, and Officials) is known and also when all the competitors for one particular event unit are known.
For team event units this message is sent as soon as the teams are available (maybe first teams, and after another message with team members).
In the final round of the team event, the Start List message is expected after the last jump of the third group. This message should contain the final alignment of the fourth group competitors.
This Start List message should be followed by a DT_RT_RESULT message with the Result status Live Mandatory.
Trigger also after any major change.
Following table defines the structure of the message.
Level 1 |
Level 2 |
Level 3 |
Level 4 |
Level 5 |
Level 6 |
Level 7 |
Competition |
|
|
|
|
|
|
|
Code |
|
|
|
|
|
|
UnitInfos (0,1) |
|
|
|
|
|
|
|
UnitDateTime (0,1) |
|
|
|
|
|
|
|
StartDate |
|
|
|
|
Officials (0,1) |
|
|
|
|
|
|
|
Official (1,N) |
|
|
|
|
|
|
|
Code |
|
|
|
|
|
|
Function |
|
|
|
|
|
|
Order |
|
|
|
|
|
|
ExtOfficial (0,N) |
|
|
|
|
|
|
|
Type |
|
|
|
|
|
|
Code |
|
|
|
|
|
|
Pos |
|
|
|
|
|
|
Value |
|
|
|
Start (0,N) |
|
|
|
|
|
|
|
StartOrder |
|
|
|
|
|
|
SortOrder |
|
|
|
|
|
|
Competitor |
|
|
|
|
|
|
|
Code |
|
|
|
|
|
|
Type |
|
|
|
|
|
|
Bib |
|
|
|
|
|
|
Composition (0,1) |
|
|
|
|
|
|
|
Athlete (1,N) |
|
|
|
|
|
|
|
Code |
|
|
|
|
|
|
Order |
|
|
|
|
|
|
Bib |
|
|
|
|
|
|
EventUnitEntry (0,N) |
|
|
|
|
|
|
|
Type |
|
|
|
|
|
|
Code |
|
|
|
|
|
|
Pos |
|
|
|
|
|
|
Value |
Competition
Attribute |
M/O |
Value |
Comments |
Code |
M |
Unique ID for competition |
UnitInfos /UnitDateTime
Scheduled start date and time.
Attribute |
M/O |
Value |
Comments |
StartDate |
M |
DateTime |
Actual start date and time. For multiday units, the start time is on the first day. |
Officials /Official
Official associated to the event unit.
Attribute |
M/O |
Value |
Comments |
Code |
M |
S(20) with no leading zeroes |
Key of the official, to uniquely identify this element |
Function |
M |
Send the function code for: FIS Race Director FIS Technical Delegate Chief of Competition FIS Assistant Technical Delegate FIS Assistant Race Director FIS Equipment Controller Judge |
|
Order |
M |
Numeric |
Order of the Officials following the Sports Rule |
Officials /Official /ExtOfficial
Official’s extended information.
Type |
Code |
Pos |
Value |
Description |
EO_SJ |
SJ_POSITION |
|
S(2) |
For @Type: Send proposed type For @Code: Send proposed code For @Value: Position of the Judge, i.e. A, B, C, SC… |
SJ_JUDGE |
|
S(2) Y,N,SC |
For @Type: Send proposed type For @Code: Send proposed code For @Value: Send ‘SC’ if the official is a Start Controller. Send ‘Y’ if the official is a Judge but not the Start Controller. Send ‘N’ for the rest of the officials. |
For the table above, we have the following additional/summary information:
Type/Code |
Description |
Expected |
EO_SJ/ SJ_POSITION |
Position of the Judge. |
Always |
EO_SJ/ SJ_JUDGE |
Indicates if the official is a Judge. |
Always |
Start
This element is optional (due to the information availability, the information related to the event unit can be sent before the competitors information).
Attribute |
M/O |
Value |
Comments |
StartOrder |
M |
Numeric |
Start order of the competitor in the start list (either single athlete or team).
In the case of team competitor, start order of the team. The team members will have the order within the team in their respective Competitor /Composition /Athlete elements (@Order attribute). |
SortOrder |
M |
Numeric |
Same as @StartOrder |
Start /Competitor
Competitor participating in the event unit
Start /Competitor /Composition is optional for a similar reason: knowing the teams participating in one event unit, it is not known yet the team members participating.
Attribute |
M/O |
Value |
Comments |
Code |
M |
S(20) with no leading zeroes |
Competitor’s ID |
Type |
M |
T,A |
T for team A for athlete |
Bib |
O |
N(3) 999 |
Team’s bib number, to be sent mandatory just in the case of team event units |
Start /Competitor /Composition /Athlete
Athlete or team member’s extended information.
Attribute |
M/O |
Value |
Comments |
Code |
M |
S(20) with no leading zeroes |
Athlete’s ID, corresponding to either a team member or an individual athlete |
Order |
M |
Numeric |
Order attribute used to sort team members (i.e.: 1, 2..4) in a team (if Competitor @Type=”T”) or 1 if Competitor @Type=”A”. |
Bib |
M |
For team members: N(3)-N(1) 990-9
Or
For single athletes: N(3) 999 |
Athlete’s bib number. In case of a team member it will be constructed from team’s bib and the order within the team (e.g.: for team event: “11-2” means team with bib 11 and this is the second jumper of the team). |
Start /Competitor /Composition /Athlete /EventUnitEntry
Team member or individual athlete’s event unit entry.
Type |
Code |
Pos |
Value |
Description |
EU_ENTRY |
SJ_JUMP_ORDER |
|
N(2) 99 |
For @Type: Send proposed type For @Code: Send proposed code For @Pos: Do not send anything For @Value: Field used to order the athletes in the team event final. |
SJ_QM |
|
For @Type: Send proposed type For @Code: Send proposed code For @Pos: Do not send anything For @Value: Indicates if the jumper is prequalified. |
For the table above, we have the following additional/summary information:
Type/Code |
Description |
Expected |
EU_ENTRY/ SJ_JUMP_ORDER |
Field used to order the athletes in the team event final. |
Just for Team event units. |
EU_ENTRY/ SJ_QM |
Indicates if the jumper is prequalified. |
Just for the qualification round |
The message is sorted by the Start@SortOrder attribute.
The Event Unit Results is a message containing the results of the competitors in one (individual or team) event unit.
The Event Unit Results is a mandatory message for all sports. The definition includes as much generic information as possible due to the fact that each discipline and event has its own format for the results information (example: score of a match, time in a race, distance in a throw…).
The unofficial ResultStatus is not used for trainings and trials.
The following table describes the ODF header attributes
Attribute |
Value |
Comment |
DocumentCode |
DDGEEEPUU |
The DocumentCode attribute in the ODF header will be sent according to the ODF Common Codes document (header values sheet). |
DocumentType |
DT_RESULT |
Event Unit Results message |
ResultStatus |
It indicates whether the result is official or unofficial (or intermediate, interim, partial). “OFFICIAL” / “UNOFFICIAL” / “INTERMEDIATE” / “INTERIM”/ “PARTIAL” |
|
Version |
1..V |
Version number associated to the message’s content. Ascendant number |
FeedFlag |
“P”-Production “T”-Test |
Test message or production message. |
Date |
Date |
Date when the message is generated, expressed in the local time zone where the message was produced. |
Time |
MillisTime |
Time up to milliseconds when the message is generated, expressed in the local time zone where the message was produced. |
LogicalDate |
Date |
Logical Date of events that extends until next day. If an event unit continues after midnight (24:00), all messages produced will be considered as happening at the logical date on which the event unit began (e.g. for a session which began at 21:00 on Aug 2 and ended at 1:20 on Aug 3, the output will be dated Aug 2).
The end of the logical day is defined by default at 03:00 a.m.
For messages corrections, like invalidating medals or Records, it will be the LogicalDate of the correction.
Logical Date is expressed in the local time zone where the message was produced |
Venue |
Venue where the message is generated. |
|
DocumentSubtype |
N/A |
Not used in SJ. |
Serial |
Numeric |
Sequence number for ODF-PiT messages.
Serial starts with 1 each day session at every different venue.
In the case of RT transmission, this attribute contains the last PiT message Serial number in order to ensure that RT information is processed over the last PiT information |
The following table describes the ODF header attributes
Attribute |
Value |
Comment |
DocumentCode |
DDGEEEPUU |
DD according to CC @Discipline G according to CC @DisciplineGender EEE according to CC @Event P according to CC @Phase UU according to CC @Unit |
DocumentType |
DT_RT_RESULT |
Event Unit Real Time Results message |
ResultStatus |
It indicates whether the result is live update or live full (or live Mandatory, Live Last). “LIVE_UPDATE” / “LIVE_FULL” / “LIVE_MANDATORY” / “LIVE_LAST |
|
Version |
1..V |
Version number associated to the message’s content. Ascendant number |
FeedFlag |
“P”-Production “T”-Test |
Test message or production message. |
Date |
Date |
Date when the message is generated, expressed in the local time zone where the message was produced. |
Time |
MillisTime |
Time up to milliseconds when the message is generated, expressed in the local time zone where the message was produced. |
LogicalDate |
Date |
Logical Date of events that extends until next day. If an event unit continues after midnight (24:00), all messages produced will be considered as happening at the logical date on which the event unit began (e.g. for a session which began at 21:00 on Aug 2 and ended at 1:20 on Aug 3, the output will be dated Aug 2).
The end of the logical day is defined by default at 03:00 a.m.
For messages corrections, like invalidating medals or Records, it will be the LogicalDate of the correction.
Logical Date is expressed in the local time zone where the message was produced |
Venue |
Venue where the message is generated. |
|
RTSerial |
Numeric |
Incremental and unique sequence number for ODF-RT messages. |
Serial |
Numeric |
Sequence number for ODF-PiT messages.
Serial starts with 1 each day session at every different venue.
In the case of RT transmission, this attribute contains the last PiT message Serial number in order to ensure that RT information is processed over the last PiT information |
The general rule is that this message is sent when the event unit finishes and the results are still unofficial.
Also, this message is expected when the results become official. The official/unofficial status is included in the ODF headers (ResultStatus attribute).
Trigger also after any major change.
• For ResultStatus=LIVE_UPDATE:
o T1: Trigger when the gate number is known
o T2: Trigger when the traffic lights turns to green( the competitor starts the jump)
o T3: Trigger when each competitor completes his jump
o T4: Trigger when the results are known
o T5: Trigger at the beginning of each Group (Team competition)
• For ResultStatus=LIVE_FULL
Send as it will be defined for each RT transmission in the parameters of the DT_RT_GM message.
• For ResultStatus=LIVE_MANDATORY
It is sent when a correction in the previous messages has to be done.
• For ResultStatus=LIVE_LAST
Send as the last message (that indicates that no new messages are expected for the given ODF unique key, unless something unexpected, that needs correction of previous messages data, happens while the transmission is still open (Good night message has not been sent)).
Following table defines the structure of the message.
Level 1 |
Level 2 |
Level 3 |
Level 4 |
Level 5 |
Level 6 |
Level 7 |
Level 8 |
Competition |
|
|
|
|
|
|
|
|
Code |
|
|
|
|
|
|
|
UnitInfos (0,1) |
|
|
|
|
|
|
|
|
UnitDateTime (0,1) |
|
|
|
|
|
|
|
|
StartDate |
|
|
|
|
|
|
|
EndDate |
|
|
|
|
|
|
UnitInfo (0,N) |
|
|
|
|
|
|
|
|
Type |
|
|
|
|
|
|
|
Code |
|
|
|
|
|
|
|
Pos |
|
|
|
|
|
|
|
Value |
|
|
|
|
|
Result (1,N) |
|
|
|
|
|
|
|
|
Rank |
|
|
|
|
|
|
|
RankEqual |
|
|
|
|
|
|
|
Result |
|
|
|
|
|
|
|
IRM |
|
|
|
|
|
|
|
QualificationMark |
|
|
|
|
|
|
|
SortOrder |
|
|
|
|
|
|
|
ResultType |
|
|
|
|
|
|
|
Competitor (1,N) |
|
|
|
|
|
|
|
|
Code |
|
|
|
|
|
|
|
Type |
|
|
|
|
|
|
|
Bib |
|
|
|
|
|
|
|
ExtendedResults (0,1) |
|
|
|
|
|
|
|
|
ExtendedResult (1,N) |
|
|
|
|
|
|
|
|
Type |
|
|
|
|
|
|
|
Code |
|
|
|
|
|
|
|
Pos |
|
|
|
|
|
|
|
Value |
|
|
|
|
|
Composition |
|
|
|
|
|
|
|
|
Athlete (1,N) |
|
|
|
|
|
|
|
|
Code |
|
|
|
|
|
|
|
Order |
|
|
|
|
|
|
|
Bib |
|
|
|
|
|
|
|
ExtendedResults (0,1) |
|
|
|
|
|
|
|
|
ExtendedResult (1,N) |
|
|
|
|
|
|
|
|
Type |
|
|
|
|
|
|
|
Code |
|
|
|
|
|
|
|
Pos |
|
|
|
|
|
|
|
Value |
Competition
Attribute |
M/O |
Value |
Comments |
RT Only |
RT Trigger |
Code |
M |
Unique ID for competition |
N |
When available |
UnitInfos /UnitDateTime
Actual start –and/or end- dates and times.
This element is just for PiT.
Attribute |
M/O |
Value |
Comments |
RT Only |
RT Trigger |
StartDate |
O |
DateTime |
Actual start date-time. For multi-day units, the start date-time is that on the first day. |
N |
When available |
EndDate |
O |
DateTime |
Actual end date-time (The attribute should be informed, when available, for ResultStatus UNOFFICIAL and OFFICIAL) |
N |
When available |
UnitInfos /UnitInfo
Unit info item associated to the event unit.
Type |
Code |
Pos |
Value |
Description |
UI_GENERAL |
SJ_ATTENDANCE |
|
N(6) 999999 |
For @Type: Send proposed type For @Code: Send proposed code For @Pos: Do not send anything For @Value: Number of spectators |
UI_SJ |
SJ_BASE_GATE |
N(1) 9 |
Numeric |
For @Type: Send proposed type For @Code: Send proposed code For @Pos: For team events: send the number of the group (1,2,3,4) For individual events: send 0 For @Value: Base Gate |
SJ_DIST_BEAT |
N(1) 9 |
N(4).N(1) 9990.0 |
For @Type: Send proposed type For @Code: Send proposed code For @Pos: Number of the rank. It’s a sequential number from 1 to 3. For @Value: Send the distance needed (to beat) for the corresponding rank (in @Pos) in meters (with one decimal digit) for a competitor in the final. Do not send for the first competitor. |
|
SJ_LAST_QUALIFIED |
|
S(20) with no leading zeroes |
For @Type: Send proposed type For @Code: Send proposed code For @Pos: Do not send anything For @Value: For the team competition first round: it is the code of the last qualified team. For Individual qualification and first round: it is the code of the last qualified athlete. Don’t send until the moment when a competitor is ranked in this position. |
For the table above, we have the following additional/summary information:
Type/Code |
Description |
Expected |
RT Only |
RT Trigger |
UI_GENERAL/ SJ_ATTENDANCE |
Number of spectators |
Always, if available |
N |
When available |
UI_SJ/ SJ_BASE_GATE |
Base Gate of a group (@Pos 1,2,3,4 in the team events) or an individual athlete (@Pos 0 in the individual events). |
Always |
N |
When available |
UI_SJ/ SJ_DIST_BEAT |
Distance needed (to beat) for the corresponding rank (in @Pos) for a competitor. |
Just for Final rounds of Individual or Team events (except if competitor is the first one) |
Y |
T4 |
UI_SJ/ SJ_LAST_QUALIFIED |
For the team competition first round: it is the code of the last qualified team. For Individual qualification and first round: it is the code of the last qualified athlete. Don’t send until the moment when a competitor is ranked in this position. |
For Individual and Team events (all phases excepting final, training and trial). |
N |
T4 |
Result
For each Event Unit Results message, there must be at least one competitor being awarded with a result in the event unit.
Attribute |
M/O |
Value |
Comments |
RT Only |
RT Trigger |
Rank |
O |
Numeric |
Rank of the competitor in the corresponding event unit. This attribute is optional because the skier could get an invalid rank mark. Don’t send this attribute for prequalified jumpers in the Qualification phase. |
N |
T4 |
RankEqual |
O |
Y or N |
It identifies if a rank has been equalled. For Pit just include this attribute in case of equalled ranks with value "Y". |
N |
T4 |
Result |
O |
N(4).N(1) 9990.0 |
Result points for the particular event unit
Send just in the case @ResultType requests for this (see codes section) |
N |
T4 |
IRM |
O |
IRM for the particular event unit
Send according @ResultType casuistic (see codes section) |
N |
T4 |
|
QualificationMark |
O |
Send just in the case when the jumper qualifies, according to the codes |
N |
T4 |
|
SortOrder |
M |
Numeric |
This attribute is a sequential number with the order of the results for the particular event unit, if they were to be presented. It is mostly based on the rank, but it should be used to sort out rank ties as well as results without rank.
SortOrder should also take care of IRM rules (please, refer to CC @IRM)
(further order detail: Competition, Quali by Points for this round only and Training and Trial by start order)
Also for Real Time, any sort order change from the initial start list order for any competitor will be provided in this attribute regardless the competitor is ranked or not (this includes ranked, none-ranked and IRM athletes/team). |
N |
T4 |
ResultType |
O |
Result type |
N |
T4 |
Result /Competitor
Competitor related to the result of one event unit.
Attribute |
M/O |
Value |
Comments |
RT Only |
RT Trigger |
Code |
M |
S(20) with no leading zeroes |
Competitor’s ID |
N |
T4 |
Type |
M |
T,A |
T for team A for athlete |
N |
T4 |
Bib |
O |
N(3) 990 |
Team’s bib number, to be sent mandatory just in the case of team event units |
N |
T4 |
Result /Competitor /ExtendedResults /ExtendedResult
Type and extension Type |
Code |
Extension Code |
Pos or extension Pos |
Value or extension Value |
Description |
ER_SJ |
SJ_GROUP |
|
N(1) 9 |
N/A |
For @Type: Send proposed type For @Code: Send proposed code For @Pos: Number of group, one team member-. It’s a sequential number from 1 to 4, between different members of the team. For @Value: Do not send anything |
SJ_RANK |
|
N(1) 9 |
For @Type: Send proposed code (as type) For @Code: Send proposed extension code For @Pos: Do not send anything For @Value: Team’s rank in the group (used only in the team events except trial). Not used in the case of IRM. |
||
SJ_ERANK |
|
S(1) (Y) |
For @Type: Send proposed code (as type) For @Code: Send proposed extension code For @Pos: Do not send anything For @Value: It identifies if the rank of the team’s member has been equalled, send “Y” in this case. (used only in the team events except trial). Not used in the case of IRM. |
||
SJ_ORDER |
|
N(2) 90 |
For @Type: Send proposed code (as type) For @Code: Send proposed extension code For @Pos: Do not send anything For @Value: Result’s order at this Group result (based in the rank). (used only in the team events except trial). |
||
SJ_CURRENT |
|
|
S(1) (Y,N) |
For @Type: Send proposed type For @Code: Send proposed code For @Pos: Do not send anything For @Value: Send “Y” when this team is currently jumping, and “N” otherwise (if not and it has changed). |
|
SJ_LAST_FINISHED |
|
|
S(1) (Y,N) |
For @Type: Send proposed type For @Code: Send proposed code For @ Pos: Do not send anything For @Value: Send “Y” when the last results corresponds to this competitor of a group (finishes the jump), “N” otherwise. |
|
SJ_NEXT |
|
|
S(1) (Y,N) |
For @Type: Send proposed type For @Code: Send proposed code For @ Pos: Do not send anything For @Value: Send “Y” when this team is the next to jump, “N” otherwise. |
For the table above, we have the following additional/summary information:
Type/Code/Extension Code |
Description |
Expected |
RT Only |
RT Trigger |
ER_SJ/ SJ_GROUP |
Team’s results at each group (per leg): rank, equalled rank and order achieved by the team’s members. |
Always, just for Team event units (except Trial Round) |
N |
T4 |
ER_SJ/ SJ_GROUP/ SJ_RANK |
Team’s results at each group (per leg): rank, equalled rank and order achieved by the team’s members. Not used in the case of IRM. |
Always, just for Team event units (except Trial Round) |
N |
T4 |
ER_SJ/ SJ_GROUP/ SJ_ERANK |
Team’s results at each group (per leg): rank, equalled rank and order achieved by the team’s members. Not used in the case of IRM. |
Always, just for Team event units (except Trial Round) |
N |
T4 |
ER_SJ/ SJ_GROUP/ SJ_ORDER |
Team’s results at each group (per leg): rank, equalled rank and order achieved by the team’s members. |
Always, just for Team event units (except Trial Round) |
N |
T4 |
ER_SJ/ SJ_CURRENT |
Indicates that this team is currently jumping. |
Always, just for Team event units (except Trial Round) |
Y |
T5 |
ER_SJ/ SJ_LAST_FINISHED |
Indicates that this team has just finished the jump. |
Always, just for Team event units (except Trial Round) |
Y |
T5 |
ER_SJ/ SJ_NEXT |
Indicates that this team (a team member) is the next to jump. |
Always, just for Team event units (except Trial Round) |
Y |
T5 |
Result /Competitor /Composition /Athlete
Attribute |
M/O |
Value |
Comments |
RT Only |
RT Trigger |
Code |
M |
S(20) with no leading zeroes |
Athlete’s ID. Can belong to a team member or an individual athlete. |
N |
T4 |
Order |
M |
Numeric |
Order attribute used to sort team members in a team (if Competitor @Type=”T”) or 1 if Competitor @Type=”A”. |
N |
T4 |
Bib |
M |
For team members: N(3)-N(1) 990-9
Or
For individual athletes: N(3) 990 |
Athlete’s bib number. In case of a team member it will be constructed from team’s bib and the order within the team (e.g.: for team event: “11-2” means team with bib 11 and this is the second jumper of the team). |
N |
T4 |
Result /Competitor /Composition /Athlete /ExtendedResults /ExtendedResult
Team member or individual athlete’s extended result.
Type |
Code |
Pos |
Value |
Description |
ER_SJ |
SJ_LENGTH |
|
N(4).N(1) 9990.0 |
For @Type: Send proposed type For @Code: Send proposed code For @Pos: Do not send anything For @Value: Send jump length in meters, with one decimal digit |
SJ_LENGTH_POINTS |
|
N(4).N(1) 9990.0
Or
-N(4).N(1) -9990.0 |
For @Type: Send proposed type For @Code: Send proposed code For @Pos Do not send anything For @Value: Send points for length, with one decimal digit |
|
SJ_SPEED |
|
N(4).N(1) 9990.0 |
For @Type: Send proposed type For @Code: Send proposed code For @Pos: Do not send anything For @Value: Speed in km/h, with one decimal digit |
|
SJ_JUMP_POINTS |
|
N(4).N(1) 9990.0 |
For @Type: Send proposed type For @Code: Send proposed code For @Pos: Do not send anything For @Value: Send points for jump, with one decimal digit |
|
SJ_JUDGE |
Numeric |
N(2).N(1) 90.0 |
For @Type: Send proposed type For @Code: Send proposed code For @Pos: Send judge number, from 1 to 5 For @Value: Send points from the judge identified by @Pos, with one decimal digit. |
|
SJ_JUDGE_CROSS |
Numeric |
S(1) Y or N |
For @Type: Send proposed type For @Code: Send proposed code For @Pos: Send judge number, from 1 to 5 For @Value: Send Y or N for the crossed judge points from the judge identified by @Pos. |
|
SJ_JUDGES |
|
N(2).N(1) 90.0 |
For @Type: Send proposed type For @Code: Send proposed code For @Pos: Do not send anything For @Value: Send total points from judges, with one decimal digit |
|
SJ_IND_IRM |
|
For @Type: Send proposed type For @Code: Send proposed code For @Pos: Do not send anything For @Value: Invalid result mark for an individual in a team event unit (team member) |
||
SJ_RULE |
|
Text |
For @Type: Send proposed type For @Code: Send proposed code For @ Pos: Do not send anything For @Value: Rule Number |
|
SJ_RULE_TEXT |
|
Text |
For @Type: Send proposed type For @Code: Send proposed code For @ Pos: Do not send anything For @Value: Rule text |
|
SJ_GATE |
|
S(6) |
For @Type: Send proposed type For @Code: Send proposed code For @ Pos: Do not send anything For @Value: Start Gate position |
|
SJ_RANK_SPEED |
|
Numeric |
For @Type: Send proposed type For @Code: Send proposed code For @ Pos: Do not send anything For @Value: Rank for the speed overall |
|
SJ_RANK_DISTANCE |
|
Numeric |
For @Type: Send proposed type For @Code: Send proposed code For @ Pos: Do not send anything For @Value: Rank for the jump distance overall |
|
SJ_RANK |
|
Numeric |
For @Type: Send proposed type For @Code: Send proposed code For @ Pos: Do not send anything For @Value: Overall rank of the athlete for the jump. Used just in the team trial event. |
|
SJ_ERANK |
|
Y or N |
For @Type: Send proposed type For @Code: Send proposed code For @ Pos: Do not send anything For @Value: It identifies if the rank has been equalled, send “Y” in this case. Used just in the team trial event. |
|
SJ_COMP_GATE |
|
N(2).N(1) 90.0
Or
-N(2).N(1) -90.0 |
For @Type: Send proposed type For @Code: Send proposed code For @ Pos: Do not send anything For @Value: Gate compensation points Send empty when base gate. Send 0.0 if no other value available. |
|
SJ_TANG_WIND |
|
N(1).N(2) 0.00
Or
-N(1).N(2) -0.00 |
For @Type: Send proposed type For @Code: Send proposed code For @ Pos: Do not send anything For @Value: Tangential wind speed.
Send 0.00 if no other value available. |
|
SJ_COMP_WIND |
|
N(2).N(1) 90.0
Or
-N(2).N(1) -90.0 |
For @Type: Send proposed type For @Code: Send proposed code For @ Pos: Do not send anything For @Value: Wind compensation points.
Send 0.0 if no other value available. |
|
SJ_COMP_TOTAL |
|
N(2).N(1) 90.0
Or
-N(2).N(1) -90.0 |
For @Type: Send proposed type For @Code: Send proposed code For @ Pos: Do not send anything For @Value: Total compensation points (Gate compensation points plus Wind compensation points).
Send 0.0 if no other value available. |
|
SJ_CURRENT |
|
S(1) (Y,N) |
For @Type: Send proposed type For @Code: Send proposed code For @Pos: Do not send anything For @Value: Send Y when this competitor is currently jumping and he didn't receive the total score, and N otherwise (if not and it has changed). |
|
SJ_LAST_FINISHED |
|
S(1) (Y,N) |
For @Type: Send proposed type For @Code: Send proposed code For @ Pos: Do not send anything For @Value: Send “Y” when this competitor is the last finished the jump, “N” otherwise. |
|
SJ_NEXT |
|
S(1) (Y,N) |
For @Type: Send proposed type For @Code: Send proposed code For @ Pos: Do not send anything For @Value: Send “Y” when this competitor is the next to jump, “N” otherwise. |
|
SJ_IRF |
|
S(1) (Y,N) |
For @Type: Send proposed type For @Code: Send proposed code For @ Pos: Do not send anything For @Value: Send “Y” when the athlete is in ‘Inrun fall’. Else send ‘N’ |
|
SJ_IDX_ORDER |
|
Numeric |
For @Type: Send proposed type For @Code: Send proposed code For @ Pos: Do not send anything For @Value: Send the display order of the athlete in the team trial event.
Any idx order change from the initial start list order for any competitor will be provided in this attribute regardless the competitor is ranked or not (this includes ranked, none-ranked and IRM athletes/team).
Used just in the team trial event. |
|
SJ_JUMP_FINISHED |
|
S(1) (Y,N) |
For @Type: Send proposed type
For @Code: Send proposed code
For @ Pos: Do not send anything
For @Value: Send “Y” when this competitor is the last receiving his distance result, “N” when the final result is received or otherwise. |
For the table above, we have the following additional/summary information:
Type/Code |
Description |
Expected |
RT Only |
RT Trigger |
ER_SJ/ SJ_LENGTH |
Jump length in meters |
Always |
N |
T3 |
ER_SJ/ SJ_LENGTH_POINTS |
Points for length |
Always |
N |
T4 |
ER_SJ/ SJ_SPEED |
Speed in km/h |
Always |
N |
T2 |
ER_SJ/ SJ_JUMP_POINTS |
Points for jump |
Always, except for Training and Trial (individual) and except for prequalified jumpers in the Qualification Phase |
N |
T4 |
ER_SJ/ SJ_JUDGE |
Points for a particular judge |
Just in competition round (first round and final round) and qualification (except for prequalified jumpers) |
N |
T4 |
ER_SJ/ SJ_JUDGE_CROSS |
Status indicating if the points for a particular judge are crossed or not. |
Just in competition round (first round and final round) and qualification (except for prequalified jumpers) |
N |
T4 |
ER_SJ/ SJ_JUDGES |
Total points from judges |
Just in competition round (first round and final round) and qualification (except for prequalified jumpers) |
N |
T4 |
ER_SJ/ SJ_IND_IRM |
Invalid result mark for a team member. |
Just in case of team event unit, if not team-trial |
N |
T4 |
ER_SJ/ SJ_RULE |
Rule Text of Disqualification |
Just in case of Disqualification |
N |
When available |
ER_SJ/ SJ_RULE_TEXT |
Rule Number of Disqualification |
Just in case of Disqualification |
N |
When available |
ER_SJ/ SJ_GATE |
Start Gate position |
Always |
N |
T1 |
ER_SJ/ SJ_RANK_SPEED |
Rank for the speed overall |
Always in the Training and Trial events |
N |
T4 |
ER_SJ/ SJ_RANK_DISTANCE |
Rank for the jump distance overall |
Always in the Training and Trial events |
N |
T4 |
ER_SJ/ SJ_RANK |
Overall rank of the athlete for the jump in the team trial event. |
Always in the Training and Trial events |
N |
T4 |
ER_SJ/ SJ_ERANK |
Equalled rank |
Always in the Training and Trial events |
N |
T4 |
ER_SJ/ SJ_COMP_GATE |
Gate compensation points. Send empty when base gate. Is 0.0 when no other value available. |
Always |
N |
T4 |
ER_SJ/ SJ_TANG_WIND |
Tangential wind speed
Is 0.00 when no other value available. |
Always |
N |
When available |
ER_SJ/ SJ_COMP_WIND |
Wind compensation points
Is 0.0 when no other value available. |
Always |
N |
T4 |
ER_SJ/ SJ_COMP_TOTAL |
Total compensation points (gate plus wind).
Is 0.0 when no other value available. |
Always |
N |
T4 |
ER_SJ/ SJ_CURRENT |
Indicates that this competitor is currently jumping and he didn't receive the total score . |
Always |
Y |
T4 |
ER_SJ/ SJ_LAST_FINISHED |
Indicates that this competitor has just finished the jump. |
Always |
Y |
T4 |
ER_SJ/ SJ_NEXT |
Indicates that this competitor is the next to jump. |
Always |
Y |
T4 |
ER_SJ/ SJ_IRF |
Indicates that this competitor is in ‘Inrun fall’ |
Always |
N |
When available |
ER_SJ/ SJ_IDX_ORDER |
Send the display order of the athlete in the team trial event.
Any idx_order changed from the initial start list order for any competitor, will be provided in this attribute regardless the competitor is ranked or not (this includes ranked, none-ranked and IRM athletes/team). |
Always in the Team Trial event. |
Y |
T4 |
ER_SJ/ SJ_JUMP_FINISHED |
Send “Y” when this competitor is the last receiving his distance result, “N” when the final result is received or otherwise. |
Always |
Y |
T3 |
Sort by Result @SortOrder
The Cumulative Results is a message containing the cumulative results for the list of competitors in one phase, up to the end of this phase (including information regarding to previous phases), or up to the end of an event unit within a phase (including also the units prior the current one) either competing as single athletes or as aggregated athletes according to the team definition.
The difference between the Phase Results message (DT_PHASE_RESULTS) and the Cumulative Results (DT_CUMULATIVE_RESULT) is that the first one includes only the results for the phase independently from previous phases, while the Cumulative Results takes into account the results of previous phases, and therefore it gives an idea about how a competition is progressing up to the end of an intermediate phase.
The Cumulative Results message may be used to send an interim summary of results (including rank) part way through a phase. In this case, the DocumentSubtype is used to specify the last phase or event unit that contributed results to the message.
The mandatory attributes and mandatory elements defined in this message will have to be used by all the sports, although each ODF Sport Data Dictionary will have to explain with further detail the optional attributes or optional elements of the message.
The following table describes the ODF header attributes
Attribute |
Value |
Comment |
DocumentCode |
DDGEEE000 |
DD according to CC @Discipline G according to CC @DisciplineGender EEE according to CC @Event |
DocumentType |
DT_CUMULATIVE_RESULT |
Cumulative Results message |
ResultStatus |
It indicates whether the result is official or unofficial. “OFFICIAL” / “UNOFFICIAL” |
|
DocumentSubtype |
DDGEEEPUU |
Cumulative results up to the end of the referenced event unit.
However, it only applies to event units of phase 1 of competition excepting the trial round (neither to be sent for qualification phases). |
Version |
1..V |
Version number associated to the message’s content. Ascendant number |
FeedFlag |
“P”-Production “T”-Test |
Test message or production message. |
Date |
Date |
Date when the message is generated, expressed in the local time zone where the message was produced. |
Time |
MillisTime |
Time up to milliseconds when the message is generated, expressed in the local time zone where the message was produced. |
LogicalDate |
Date |
Logical Date of events that extends until next day. If an event unit continues after midnight (24:00), all messages produced will be considered as happening at the logical date on which the event unit began (e.g. for a session which began at 21:00 on Aug 2 and ended at 1:20 on Aug 3, the output will be dated Aug 2).
The end of the logical day is defined by default at 03:00 a.m.
For messages corrections, like invalidating medals or Records, it will be the LogicalDate of the correction.
Logical Date is expressed in the local time zone where the message was produced |
Venue |
Venue where the message is generated. |
|
Serial |
Numeric |
Sequence number for ODF-PiT messages.
Serial starts with 1 each day session at every different venue.
In the case of RT transmission, this attribute contains the last PiT message Serial number in order to ensure that RT information is processed over the last PiT information |
The following table describes the ODF header attributes
Attribute |
Value |
Comment |
DocumentCode |
DDGEEE000 |
DD according to CC @Discipline G according to CC @DisciplineGender EEE according to CC @Event |
DocumentType |
DT_RT_CUMULATIVE_RESULT |
Cumulative Real Time Results message |
DocumentSubtype |
CC @Phase or CC @Unit |
It is the RSC code up to the moment the cumulative message contains information:
E.g.: DDGEEEPUU would be cumulative results up to the end of the referenced event unit E.g.: DDGEEEP00 would be cumulative results up to the end of the referenced phase |
ResultStatus |
It indicates whether the result is live update or live full (or live Mandatory, Live Last). “LIVE_UPDATE” / “LIVE_FULL” / “LIVE_MANDATORY” / “LIVE_LAST”
For Real Time, live update (for the normal operative), or live full for the resynchronization messages, as explained in chapter 6.1 and ResultStatus codes as seen in chapter 3, live Mandatory when there is a correction of previous messages and Live Last for the last message of this key of messages. |
|
Version |
1..V |
Version number associated to the message’s content. Ascendant number |
FeedFlag |
“P”-Production “T”-Test |
Test message or production message. |
Date |
Date |
Date when the message is generated, expressed in the local time zone where the message was produced. |
Time |
MillisTime |
Time up to milliseconds when the message is generated, expressed in the local time zone where the message was produced. |
LogicalDate |
Date |
Logical Date of events that extends until next day. If an event unit continues after midnight (24:00), all messages produced will be considered as happening at the logical date on which the event unit began (e.g. for a session which began at 21:00 on Aug 2 and ended at 1:20 on Aug 3, the output will be dated Aug 2).
The end of the logical day is defined by default at 03:00 a.m.
For messages corrections, like invalidating medals or Records, it will be the LogicalDate of the correction.
Logical Date is expressed in the local time zone where the message was produced |
Venue |
Venue where the message is generated. |
|
RTSerial |
Numeric |
Incremental and unique sequence number for ODF-RT messages. |
Serial |
Numeric |
Sequence number for ODF-PiT messages.
Serial starts with 1 each day session at every different venue.
In the case of RT transmission, this attribute contains the last PiT message Serial number in order to ensure that RT information is processed over the last PiT information |
The general rule is that this message is sent as soon as:
If results are accumulating accross phases (i.e. the message is sent at event level and the Document Subtype of the message is DDGEEEP00):
It is sent after the last event unit for the first phase, in addition to subsequent phases. The message becomes unofficial just at the end of the event unit, and afterwards when the message becomes official (when the last event unit becomes official).
If results are accumulated across event units (i.e. the message is sent at phase level and the Document Subtype of the message is DDGEEEPUU):
It is sent after the first event unit, in addition to subsequent event units; (in this case, the first DT_CUMULATIVE_RESULT message and the DT_RESULT message may contain the same information).The message becomes unofficial just at the end of the event unit, and afterwards when the message becomes official (when the last event unit becomes official).
The sequence is clarified below. The version number, n, is the version of the last DT_RESULT message sent for the same RSC code (n=0 if no DT_RESULT messages have been sent). The version number, m, is the version of the last DT_CUMULATIVE_RESULT message sent for the same RSC code (m=0 if no DT_CUMULATIVE_RESULT messages have been sent).
The clarification of this sequence can be:
Case 1:
a) Event has been complete and the results are unofficials:
1. Sent DT_RESULT with ODF Version n+1 and ResultStatus =” UNOFFICIAL”.
2. Sent DT_CUMULATIVE_RESULT with ODF Version m+1 and ResultStatus =” UNOFFICIAL”.
b) Results are checked and signed off by referee:
1. Sent DT_RESULT with ODF Version n+2 and ResultStatus =” OFFICIAL”.
2. Sent DT_CUMULATIVE_RESULT with ODF Version m+2 and ResultStatus =” OFFICIAL”.
Case 2:
a) Event has been complete and the results are directly officials:
1. Sent DT_RESULT with ODF Version n+1 and ResultStatus =” OFFICIAL”.
2. Sent DT_CUMULATIVE_RESULT with ODF Version m+1 and ResultStatus =” OFFICIAL”.
Trigger also after any major change.
However, if there is any kind of sport specific rule, it may be overridden in each of the ODF Sport Data Dictionaries: example to send interim results, partial results, etc.
• For ResultStatus=LIVE_UPDATE:
o T4: Trigger when the results are known (after the competitor completes his jump)
• For ResultStatus=LIVE_FULL:
Send as it will be defined for each RT transmission in the parameters of the DT_RT_GM message.
• For ResultStatus=LIVE_MANDATORY
It is sending when a correction in the previous messages has been done.
• For ResultStatus=LIVE_LAST
Send as the last message (that indicates that no new messages are expected for the given ODF unique key, unless something unexpected, that needs correction of previous messages data, happens while the transmission is still open (Good night message has not been sent)).
• For ResultStatus=LIVE_LAST
Send as the last message (that indicates that no new messages are expected for the given ODF unique key, unless something unexpected, that needs correction of previous messages data, happens while the transmission is still open (Good night message has not been sent)).
Following table defines the structure of the message.
Level 1 |
Level 2 |
Level 3 |
Level 4 |
Level 5 |
Level 6 |
Competition |
|
|
|
|
|
|
Code |
|
|
|
|
|
Result (1,N) |
|
|
|
|
|
|
Rank |
|
|
|
|
|
RankEqual |
|
|
|
|
|
ResultType |
|
|
|
|
|
Result |
|
|
|
|
|
IRM |
|
|
|
|
|
QualificationMark |
|
|
|
|
|
SortOrder |
|
|
|
|
|
ResultItems |
|
|
|
|
|
|
ResultItem (1,N) |
|
|
|
|
|
|
Phase |
|
|
|
|
|
Unit |
|
|
|
|
|
Result |
|
|
|
|
|
|
Rank |
|
|
|
|
|
RankEqual |
|
|
|
|
|
ResultType |
|
|
|
|
|
Result |
|
|
|
|
|
IRM |
|
|
|
|
|
QualificationMark |
|
|
|
|
|
SortOrder |
|
|
Competitor |
|
|
|
|
|
|
Code |
|
|
|
|
|
Type |
|
|
|
|
|
Bib |
|
|
|
|
|
Composition |
|
|
|
|
|
|
Athlete (1,N) |
|
|
|
|
|
|
Code |
|
|
|
|
|
Order |
|
|
|
|
|
Bib |
Competition
Attribute |
M/O |
Value |
Comments |
RT Only |
RT Trigger |
Code |
M |
Unique ID for competition |
N |
When available |
Result
For any cumulative results message, there should be at least one competitor being awarded a cumulative result after one event unit or phase.
Attribute |
M/O |
Value |
Comments |
RT Only |
RT Trigger |
Rank |
O |
Numeric |
Cumulative rank of the competitor after the finalisation of the current event unit, so it takes into account the previous event units.
This attribute is optional because the skier may have got an invalid rank mark |
N |
T4 |
RankEqual |
O |
Y or N |
It identifies if a rank has been equalled. In PiT message only Y value has sense. |
N |
T4 |
ResultType |
O |
Result type, either points or IRM for the corresponding cumulative results |
N |
T4 |
|
Result |
O |
N(4).N(1) 9990.0 |
Result points after the finalisation of the current event unit. Points with one decimal digit.
Send just in the case @ResultType is points (see codes section) |
N |
T4 |
IRM |
O |
IRM after the finalisation of the current event unit. It will depend on the results of all the event units up to the moment of the message sending.
Send just in the case @ResultType is IRM (see codes section) |
N |
T4 |
|
QualificationMark |
O |
Send just in the case the jumper qualified, according to the codes |
N |
T4 |
|
SortOrder |
M |
Numeric |
This attribute is a sequential number with the order of the results after the finalisation of the current event unit (within the particular phase), if they were to be presented. It is mostly based on the rank, but it could be used to sort out rank ties as well as results without rank.
SortOrder should also take care of IRM rules (please, refer to CC @IRM) |
N |
T4 |
Result /ResultItems /ResultItem
Identifier of either phase or unit, for the schedule item to which it is going to be included the result summary. ResultItem /Result will be for either one particular previous phase -identified by @Phase- or unit (if @Unit is also informed or just phase otherwise.
Attribute |
M/O |
Value |
Comments |
RT Only |
RT Trigger |
Phase |
M |
Phase code of the latest RSC schedule item (either phase or unit) to which the cumulative results is updated to. |
N |
T4 |
|
Unit |
O |
Unit code of the latest RSC schedule item to which the cumulative results is updated to. |
N |
T4 |
Result /ResultItems /ResultItem /Result
For any Event Unit Results message, there should be at least one competitor being awarded a result for the event unit.
Attribute |
M/O |
Value |
Comments |
RT Only |
RT Trigger |
Rank |
O |
Numeric |
Rank of the competitor in the result for the event unit identified by /ResultsItems /ResultItem.
This attribute is optional because the competitor could get an invalid rank mark (in this case, it will be blank). |
N |
T4 |
RankEqual |
O |
Y or N |
It identifies if a rank has been equalled. In PiT message only Y value has sense. |
N |
T4 |
ResultType |
M |
Type of the @Result attribute for the event unit identified by /ResultsItems /ResultItem |
N |
T4 |
|
Result |
O |
N(4).N(1) 9990.0 |
The result of the competitor for the event unit identified by /ResultsItems /ResultItem |
N |
T4 |
IRM |
O |
The invalid rank mark, in case it is assigned for the event unit or phase identified by /ResultItems /ResultItem |
N |
T4 |
|
QualificationMark |
O |
The code which gives an indication on the qualification of the competitor for the next round of the competition for the event unit or phase identified by /ResultsItems /ResultItem |
N |
T4 |
|
SortOrder |
M |
Numeric |
Used to sort all results in an event unit or phase identified by /ResultItems /ResultItem |
N |
T4 |
Result /Competitor
Competitor related to one cumulative result.
Attribute |
M/O |
Value |
Comments |
RT Only |
RT Trigger |
Code |
M |
S(20) with no leading zeroes |
Competitor’s ID |
N |
T4 |
Type |
M |
T,A |
T for team A for athlete |
N |
T4 |
Bib |
O |
N(3) 990 |
Team’s bib number, to be sent mandatory just in the case of team event units |
N |
T4 |
Result /Competitor /Composition /Athlete
Attribute |
M/O |
Value |
Comments |
RT Only |
RT Trigger |
Code |
M |
S(20) with no leading zeroes |
Athlete’s ID, corresponding to either a team member or a single athlete |
N |
T4 |
Order |
M |
Numeric |
Order attribute used to sort team members in a team (if Competitor @Type=”T”) or 1 if Competitor @Type=”A”. |
N |
T4 |
Bib |
M |
For team members: N(3)-N(1) 990-9
Or
For individual athletes: N(3) 990 |
Athlete’s bib number. In case of a team member it will be constructed from team’s bib and the order within the team (e.g.: for team event: “11-2” means team with bib 11 and this is the second jumper of the team). |
N |
T4 |
The message sorting order is the same as that explained in the Event Unit / Phase Results messages.
The event final ranking is a message containing the final results and ranking at the completion of one particular event, either for individual athletes or for aggregated athletes.
The final ranking message is a generic message for all sports, including the full event final result for all competitors who were either ranked, got an Invalid Rank Mark (disqualified, etc.), or both.
The mandatory attributes and mandatory elements defined in this message will have to be used by all the sports, although each ODF Sport Data Dictionary will have to explain with further detail the optional attributes or optional elements of the message.
Depending on the sport rules include all competitors in the competition as all can be ranked (as in Marathon) or only include those with a final ranking as other are unranked (as in tennis).
The following table describes the ODF header attributes
Attribute |
Value |
Comment |
DocumentCode |
DDGEEE000 |
The DocumentCode attribute in the ODF header will be sent according for all the competition events to the ODF Common Codes document (header values sheet). |
DocumentType |
DT_RANKING |
Event Final ranking message |
ResultStatus |
Result status |
|
Version |
1..V |
Version number associated to the message’s content. Ascendant number |
FeedFlag |
“P”-Production “T”-Test |
Test message or production message. |
Date |
Date |
Date when the message is generated, expressed in the local time zone where the message was produced. |
Time |
MillisTime |
Time up to milliseconds when the message is generated, expressed in the local time zone where the message was produced. |
LogicalDate |
Date |
Logical Date of events that extends until next day. If an event unit continues after midnight (24:00), all messages produced will be considered as happening at the logical date on which the event unit began (e.g. for a session which began at 21:00 on Aug 2 and ended at 1:20 on Aug 3, the output will be dated Aug 2).
The end of the logical day is defined by default at 03:00 a.m.
For messages corrections, like invalidating medals or Records, it will be the LogicalDate of the correction.
Logical Date is expressed in the local time zone where the message was produced |
Venue |
Venue where the message is generated. |
|
Serial |
Numeric |
Sequence number for ODF-PiT messages.
Serial starts with 1 each day session at every different venue. |
The general rule is that this message is sent just at the end of the last event unit of one particular event.
Trigger also after any major change.
Following table defines the structure of the message.
Level 1 |
Level 2 |
Level 3 |
Level 4 |
Level 5 |
Level 6 |
Competition |
|
|
|
|
|
|
Code |
|
|
|
|
|
Result (1,N) |
|
|
|
|
|
|
Rank |
|
|
|
|
|
RankEqual |
|
|
|
|
|
ResultType |
|
|
|
|
|
Result |
|
|
|
|
|
IRM |
|
|
|
|
|
SortOrder |
|
|
|
|
|
Competitor |
|
|
|
|
|
|
Code |
|
|
|
|
|
Type |
|
|
|
|
|
Composition |
|
|
|
|
|
|
Athlete (1,N) |
|
|
|
|
|
|
Code |
|
|
|
|
|
Order |
Competition
Attribute |
M/O |
Value |
Comments |
Code |
M |
Unique ID for competition |
Result
For any event final ranking message, there should be at least one competitor being awarded a result for the event.
Attribute |
M/O |
Value |
Comments |
Rank |
O |
Numeric |
Final rank of the competitor in the corresponding event. This attribute is optional because the skier may have got an invalid rank mark. |
RankEqual |
O |
Y |
It identifies if a rank has been equalled. |
ResultType |
M |
Result type, either points or IRM for the corresponding event. |
|
Result |
O |
N(4).N(1) 9990.0 |
Final result points for the particular event. Points should have one decimal digit.
Send just in the case @ResultType is points or IRM (see codes section) |
IRM |
O |
IRM for the particular event.
Send just in the case @ResultType is IRM (see codes section) |
|
SortOrder |
M |
Numeric |
This attribute is a sequential number with the order of the results for the particular event, if they were to be presented. It is mostly based on the rank, but it could be used to sort out rank ties as well as results without rank.
SortOrder should also take care of IRM rules (please, refer to CC @IRM) |
Result /Competitor
Competitor related to one final event result.
Attribute |
M/O |
Value |
Comments |
Code |
M |
S(20) with no leading zeroes |
Competitor’s ID |
Type |
M |
T,A |
T for team A for athlete |
Result /Competitor /Composition /Athlete
Attribute |
M/O |
Value |
Comments |
Code |
M |
S(20) with no leading zeroes |
Athlete’s ID, corresponding to an individual athlete or a team member.
Team members should be participating in the event. |
Order |
M |
Numeric |
Order attribute used to sort team members in a team (if Competitor @Type=”T”) or 1 if Competitor @Type=”A”. |
Sort by Result @SortOrder
The “Event’s Medallists” is a message containing the list of medallists awarded in one particular event.
The following table describes the ODF header attributes
Attribute |
Value |
Comment |
DocumentCode |
DDGEEE000 |
DD according to CC @Discipline G according to CC @DisciplineGender EEE according to CC @Event |
DocumentType |
DT_MEDALLISTS |
Event’s Medallists message |
ResultStatus |
It indicates whether the result is official or partial. “OFFICIAL” / “PARTIAL” |
|
Version |
1..V |
Version number associated to the message’s content. Ascendant number |
FeedFlag |
“P”-Production “T”-Test |
Test message or production message. |
Date |
Date |
Date when the message is generated, expressed in the local time zone where the message was produced. |
Time |
MillisTime |
Time up to milliseconds when the message is generated, expressed in the local time zone where the message was produced. |
LogicalDate |
Date |
Logical Date of events that extends until next day. If an event unit continues after midnight (24:00), all messages produced will be considered as happening at the logical date on which the event unit began (e.g. for a session which began at 21:00 on Aug 2 and ended at 1:20 on Aug 3, the output will be dated Aug 2).
The end of the logical day is defined by default at 03:00 a.m.
For messages corrections, like invalidating medals or Records, it will be the LogicalDate of the correction.
Logical Date is expressed in the local time zone where the message was produced |
Venue |
Venue where the message is generated. |
|
Serial |
Numeric |
Sequence number for ODF-PiT messages.
Serial starts with 1 each day session at every different venue.
In the case of RT transmission, this attribute contains the last PiT message Serial number in order to ensure that RT information is processed over the last PiT information |
The message is sent with ResultStatus=PARTIAL when the information of the medallist is know but the final event Unit is not yet finished.
The message is sent with ResultStatus=OFFICIAL when the medallists are official known.
For some sports, bronze medals are known before the end of the final event unit. In this case the message is sent the first time with the bronze medallists, and the second time with all the medallists.
Trigger also after any major change.
Following table defines the structure of the message.
Level 1 |
Level 2 |
Level 3 |
Level 4 |
Level 5 |
Level 6 |
Competition |
|
|
|
|
|
|
Code |
|
|
|
|
|
Medal (1,N) |
|
|
|
|
|
|
Code |
|
|
|
|
|
Phase |
|
|
|
|
|
Unit |
|
|
|
|
|
Competitor |
|
|
|
|
|
|
Type |
|
|
|
|
|
Code |
|
|
|
|
|
Order |
|
|
|
|
|
Composition |
|
|
|
|
|
|
Athlete (1,N) |
|
|
|
|
|
|
Code |
|
|
|
|
|
Order |
Competition
Attribute |
M/O |
Value |
Comments |
Code |
M |
Unique ID for competition |
Medal
Attribute |
M/O |
Value |
Comments |
Code |
M |
Medal type.
All the Competitors with the same CC@MedalType are not grouped in the same element. |
|
Phase |
M |
Phase code in which a medal was awarded.
It is used in case of disciplines like Ice Hockey or Basketball, with the bronze medal and the gold medal awarded in different event units. |
|
Unit |
M |
Unit code in which a medal was awarded.
It is used in case of disciplines like Ice Hockey or Basketball, with the bronze medal and the gold medal awarded in different event units. |
Medal /Competitor
Attribute |
M/O |
Value |
Comments |
Type |
M |
T, A |
T for team A for athlete |
Code |
M |
S(20) with no leading zeroes |
Competitor’s ID |
Order |
M |
Numeric |
Competitor order (Send 1 by default). In the case of tie the order is defined for the sport rules. |
Medal /Competitor /Composition /Athlete
(Include all members that won the medal according to sport rules if Competitor @Type=”T”)
Attribute |
M/O |
Value |
Comments |
Code |
M |
S(20) with no leading zeroes |
Athlete’s ID, corresponding either to a team member or an individual athlete |
Order |
M |
Numeric |
Order of the team members in a team if Competitor @Type=”T”.
1 if Competitor @Type=”A”. |
The message is sorted according to the medal type. Moreover, in case of tie the order is according to the Competitor@Order (given by the sport rule). Team members are sorted according to the Athlete@Order.
The Discipline Configuration is a message containing discipline general configuration.
Ideally the configuration for the discipline should be provided before competition. However it may be possible that the configuration for one particular event, phase or event unit is not known in advance. In that case send the unknown attributes blank (Value=“”).
The following table describes the ODF header attributes
Attribute |
Value |
Comment |
DocumentCode |
DD0000000 |
DD according to CC @Discipline |
DocumentType |
DT_CONFIG |
Discipline Configuration message |
Version |
1..V |
Version number associated to the message’s content. Ascendant number |
FeedFlag |
“P”-Production “T”-Test |
Test message or production message. |
Date |
Date |
Date when the message is generated, expressed in the local time zone where the message was produced. |
Time |
MillisTime |
Time up to milliseconds when the message is generated, expressed in the local time zone where the message was produced. |
LogicalDate |
Date |
Logical Date of events that extends until next day. If an event unit continues after midnight (24:00), all messages produced will be considered as happening at the logical date on which the event unit began (e.g. for a session which began at 21:00 on Aug 2 and ended at 1:20 on Aug 3, the output will be dated Aug 2).
The end of the logical day is defined by default at 03:00 a.m.
For messages corrections, like invalidating medals or Records, it will be the LogicalDate of the correction.
Logical Date is expressed in the local time zone where the message was produced |
Venue |
Venue where the message is generated. |
|
Serial |
Numeric |
Sequence number for ODF-PiT messages.
Serial starts with 1 each day session at every different venue.
In the case of RT transmission, this attribute contains the last PiT message Serial number in order to ensure that RT information is processed over the last PiT information |
The message is sent when:
• When this information is available.
Following table defines the structure of the message.
Level 1 |
Level 2 |
Level 3 |
Level 4 |
Level 5 |
Competition |
|
|
|
|
|
Code |
|
|
|
|
Configs |
|
|
|
|
|
Config (1,N) |
|
|
|
|
|
Gender |
|
|
|
|
Event |
|
|
|
|
Phase |
|
|
|
|
Unit |
|
|
|
|
ExtendedConfig (1,N) |
|
|
|
|
|
Type |
|
|
|
|
Code |
|
|
|
|
Pos |
|
|
|
|
Value |
Competition
Attribute |
M/O |
Value |
Comments |
Code |
M |
Unique ID for competition |
Configs /Config
Attribute |
M/O |
Value |
Comments |
Gender |
M |
Gender code of the RSC. |
|
Event |
M |
Event code of the RSC. |
|
Phase |
O |
Phase code of the RSC. There are the following phases: (O) Official Training (9) Qualification (for Individual events) (1) Competition
It should be informed just in the case that the Information is by Phase or by Event Unit. |
|
Unit |
O |
Unit code of the RSC.
It should be informed just in the case that the information is by Event Unit. |
Configs /Config /ExtendedConfig
Type |
Code |
Pos |
Value |
Description |
EC_QUALIFICATION_RULE |
SJ_RANK_QUALIFY_NEXT_ROUND (Send by event unit) |
Numeric |
Numeric |
For @Type: Send proposed type For @Code: Send the proposed code for the qualification rule.
SJ_RANK_QUALIFY_NEXT_ROUND is the code that indicates the qualification for next round based on rank. For @Pos: Send 1 to indicate first rank included in the @Code rule
Send 2 to indicate last rank included in the @Code rule For @Value: Send the rank according to @Code rule and @Pos |
SJ_PREQUALIFIED (Send by phase) |
|
Numeric |
For @Type: Send proposed type For @Code: Send the proposed code for the qualification rule.
SJ_PREQUALIFIED is the code that indicates the qualification for next round based on pre-qualification. For @Pos: Do not send anything For @Value: Send the number of pre-qualified jumpers |
|
EC_SJ (Send by event) |
SJ_HILL_TYPE |
|
For @Type: Send proposed type For @Code: Send proposed code For @Pos: Do not send anything For @Value: Hill type (Normal Hill or Large Hill) |
|
SJ_HILL_SIZE |
|
N(3) 999 |
For @Type: Send proposed type For @Code: Send proposed code For @Pos: Do not send anything For @Value: Hill size in meters |
|
SJ_K_POINT |
|
N(3) 999 |
For @Type: Send proposed type For @Code: Send proposed code For @Pos: Do not send anything For @Value: K-point in meters |
|
SJ_METRE_VALUE |
|
N(2).N(1) 90.0 |
For @Type: Send proposed type For @Code: Send proposed code For @Pos: Do not send anything For @Value: Metre value (Points per metre) |
|
SJ_GATE_FACTOR |
|
N(2).N(2) 90.00 |
For @Type: Send proposed type For @Code: Send proposed code For @Pos: Do not send anything For @Value: Gate factor (Points per metre) |
|
SJ_WIND_FACTOR |
|
N(2).N(2) 90.00 |
For @Type: Send proposed type For @Code: Send proposed code For @Pos: Do not send anything For @Value: Wind factor (Points per metre) |
|
SJ_GATE_IR_LEN |
Numeric |
N(2).N(2) m
99.99 m |
For @Type: Send proposed type For @Code: Send proposed code For @ Pos: Send from 1…n to identify each gate For @Value: In-run length of the gate |
|
SJ_GATE_NUMBER |
Numeric |
S(5) -9H |
For @Type: Send proposed type For @Code: Send proposed code For @ Pos: Send from 1…n to identify each gate For @Value: The official number of the gate |
For the table above, we have the following additional/summary information:
Type/Code |
Description |
Expected |
EC_QUALIFICATION_RULE/ SJ_RANK_QUALIFY_NEXT_ROUND (Send by event unit) |
Qualification for next round based on rank |
Send by event unit Qualification and first Round, always if the rule applies to the competition. |
EC_QUALIFICATION_RULE/ SJ_PREQUALIFIED (Send by phase) |
Qualification for next round based on pre-qualification |
Send by event unit Qualification and first Round, always if the rule applies to the competition. |
EC_SJ (Send by event)/ SJ_HILL_TYPE |
Hill type |
Always, send by event |
EC_SJ (Send by event)/ SJ_HILL_SIZE |
Hill size in metres |
Always, send by event |
EC_SJ (Send by event)/ SJ_K_POINT |
K-point in metres |
Always, send by event |
EC_SJ (Send by event)/ SJ_METRE_VALUE |
Metre value (in Points per m) |
Always, send by event |
EC_SJ (Send by event)/ SJ_GATE_FACTOR |
Gate factor (in Points per m) |
Always, send by event |
EC_SJ (Send by event)/ SJ_WIND_FACTOR |
Wind factor (in Points per m) |
Always, send by event |
EC_SJ (Send by event)/ SJ_GATE_IR_LEN |
In-run length of the gate |
Always, send by event |
EC_SJ (Send by event)/ SJ_GATE_NUMBER |
The official number of the gate |
Always, send by event |
There is no general message sorting rule.
The “Event Unit Weather Conditions” is a message containing the weather conditions in the Event Unit.
The following table describes the ODF header attributes
Attribute |
Value |
Comment |
DocumentCode |
DDGEEEPUU |
The DocumentCode attribute in the ODF header will be sent according to the ODF Common Codes document (header values sheet). |
DocumentType |
DT_WEATHER |
Weather conditions in the match message |
Version |
1..V |
Version number associated to the message’s content. Ascendant number |
FeedFlag |
“P”-Production “T”-Test |
Test message or production message. |
Date |
Date |
Date when the message is generated, expressed in the local time zone where the message was produced. |
Time |
MillisTime |
Time up to milliseconds when the message is generated, expressed in the local time zone where the message was produced. |
LogicalDate |
Date |
Logical Date of events that extends until next day. If an event unit continues after midnight (24:00), all messages produced will be considered as happening at the logical date on which the event unit began (e.g. for a session which began at 21:00 on Aug 2 and ended at 1:20 on Aug 3, the output will be dated Aug 2).
The end of the logical day is defined by default at 03:00 a.m.
For messages corrections, like invalidating medals or Records, it will be the LogicalDate of the correction.
Logical Date is expressed in the local time zone where the message was produced |
Venue |
Venue where the message is generated. |
|
Serial |
Numeric |
Sequence number for ODF-PiT messages.
Serial starts with 1 each day session at every different venue.
In the case of RT transmission, this attribute contains the last PiT message Serial number in order to ensure that RT information is processed over the last PiT information |
Once per unit and after every major change.
Following table defines the structure of the message.
Level 1 |
Level 2 |
Level 3 |
Level 4 |
Level 5 |
Competition |
|
|
|
|
|
Code |
|
|
|
|
Weather |
|
|
|
|
|
Conditions (1,N) |
|
|
|
|
|
Code |
|
|
|
|
Humidity |
|
|
|
|
Wind_Direction |
|
|
|
|
Condition (0,3) |
|
|
|
|
|
Code |
|
|
|
|
Value |
|
|
|
Temperature (0,N) |
|
|
|
|
|
Code |
|
|
|
|
Unit |
|
|
|
|
Value |
|
|
|
Wind (0,N) |
|
|
|
|
|
Code |
|
|
|
|
Unit |
|
|
|
|
Value |
Competition
Attribute |
M/O |
Value |
Comments |
Code |
M |
Unique ID for competition |
Weather /Conditions
Attribute |
M/O |
Value |
Comments |
Code |
M |
Weather Points |
|
Humidity |
M |
N(3) 990 |
Humidity in % |
Wind_Direction |
M |
Wind direction |
Weather /Conditions /Condition
Send two times in the case of Winter conditions.
Attribute |
M/O |
Value |
Comments |
Code |
M |
SKY, SNOW |
Weather conditions type |
Value |
M |
CC @SnowConditions Or CC @WeatherConditions |
CC @WeatherConditions for SKY Conditions and as CC @SnowConditions for SNOW conditions |
Weather /Conditions /Temperature
Send with two different @Code in the case of Winter conditions.
Attribute |
M/O |
Value |
Comments |
Code |
M |
AIR, SNOW |
Air, Snow temperature |
Unit |
M |
Celsius and Fahrenheit unit for temperature |
|
Value |
M |
-N(3).N(1) -990.0 or N(3).N(1) 990.0 |
Temperature in Celsius and Fahrenheit degrees (in case of positive temperature, do not send '+') |
Weather /Conditions /Wind
Attribute |
M/O |
Value |
Comments |
Code |
M |
SPEED |
Wind Speed |
Unit |
M |
Metric system unit for Wind |
|
Value |
M |
N(3).N(1) 990.0 |
Wind speed in @Unit degrees.
According to the requirements, the Base Wind will be always 0.00 |
There is no special sort order requirement for this message. Usually, Conditions@code is the attribute used to sort the conditions.
1. Training, Trial and Qualification Rounds
Message |
DocumentCode |
DocumentSubType |
ResultStatus |
Comments |
DT_START_LIST |
DDGEEEPUU |
N/A |
N/A |
Start List |
DT_RESULT |
DDGEEEPUU |
N/A |
LIVE_UPDAT |
Real Time Results |
DT_RESULT |
DDGEEEPUU |
N/A |
UNOFFICIAL |
Unofficial Results |
DT_RESULT |
DDGEEEPUU |
N/A |
LIVE_LAST |
End of Real Time Results |
DT_RESULT |
DDGEEEPUU |
N/A |
OFFICIAL |
Official Results |
2. First Round and Final Rounds
Message |
DocumentCode |
DocumentSubType |
ResultStatus |
Comments |
DT_START_LIST |
DDGEEEPUU |
N/A |
N/A |
Start List for First Round |
DT_RESULT |
DDGEEEPUU |
N/A |
LIVE_UPDAT |
Real Time Results for First Round |
DT_CUMULATIVE_RESULT |
DDGEEE000 |
DDGEEEPUU |
LIVE_UPDAT |
Real Time Cumulative Results for First Round |
DT_RESULT |
DDGEEEPUU |
N/A |
UNOFFICIAL |
Unofficial Results for First Round |
DT_RESULT |
DDGEEEPUU |
N/A |
LIVE_LAST |
End of Real Time Results for First Round |
DT_CUMULATIVE_RESULT |
DDGEEE000 |
DDGEEEPUU |
LIVE_LAST |
End of Real Time Cumulative Results for First Round |
DT_RESULT |
DDGEEEPUU |
N/A |
OFFICIAL |
Official Results for First Round |
DT_START_LIST |
DDGEEEPUU |
N/A |
N/A |
Start List for Final Round |
DT_RESULT |
DDGEEEPUU |
N/A |
LIVE_UPDAT |
Real Time Results for Final Round |
DT_CUMULATIVE_RESULT |
DDGEEE000 |
DDGEEEPUU |
LIVE_UPDAT |
Real Time Cumulative Results for Final Round |
DT_RESULT |
DDGEEEPUU |
N/A |
UNOFFICIAL |
Unofficial Results for Final Round |
DT_RESULT |
DDGEEEPUU |
N/A |
LIVE_LAST |
End of Real Time Results for Final Round |
DT_CUMULATIVE_RESULT |
DDGEEE000 |
DDGEEEPUU |
LIVE_LAST |
End of Real Time Cumulative Results for Final Round |
DT_RESULT |
DDGEEEPUU |
N/A |
OFFICIAL |
Official Results for Final Round |
DT_CUMULATIVE_RESULT |
DDGEEE000 |
DDGEEEPUU |
OFFICIAL |
Official Cumulative Results for Final Round |
DT_RANKING |
DDGEEE000 |
N/A |
OFFICIAL |
Event Final Ranking |
Format |
Entity Description |
Link |
|
S(6) |
Defined in ODF Common Codes Document
See entity Accreditation Status • The entity’s attribute to be used is Id |
||
S(7) |
Defined in ODF Common Codes Document
See entity Competition • The entity’s attribute to be used is Id |
||
S(3) |
Defined in ODF Common Codes Document
See entity Country • The entity’s attribute to be used is Id |
||
S(2) |
Defined in ODF Common Codes Document
See entity Discipline • The entity’s attribute to be used is Id
Valid disciplines contains Non-Sport attribute=’N’ |
||
S(1) |
Defined in ODF Common Codes Document
See entity Discipline Gender • The entity’s attribute is to access to the Discipline Gender entity is the combination of Discipline + Gender |
||
S(3) |
Defined in ODF Common Codes Document
See entity Event • The entity’s attribute to be used is Event • It will be related to Discipline and Gender |
||
S(30) |
Defined in ODF Common Codes Document
See entity Function • The entity’s attribute to be used is Id |
||
S(9) |
ME_BRONZE : Bronze ME_GOLD : Gold ME_SILVER : Silver |
|
|
S(3) |
Defined in ODF Common Codes Document
See entity Organization • The entity’s attribute to be used is Id |
||
S(1) |
Defined in ODF Common Codes Document
See entity Person Gender • The entity’s attribute to be used is Id |
||
S(1) |
Defined in ODF Common Codes Document
See entity Phase • The entity’s attribute to be used is Phase • It will be related to Discipline, Gender and Event |
||
S(1) |
R : Rain S : Snow |
|
|
S(12) |
Defined in ODF Common Codes Document
See entity Record • The entity’s attribute to be used is Id |
||
S(4) |
Defined in ODF Common Codes Document
See entity Record Type • The entity’s attribute to be used is RecordTye • It will be related to Discipline |
||
S(15) |
INTERIM : Results of the top x competitors at the logical, predefined points released during or at the end of a event unit. Every next competitor may change the standing of those who already have results at a predefined point. INTERMEDIATE : Results of the top x competitors at the logical, predefined points during race or match. The results at those points cannot change. The number of competitors may vary. In the case of Bracket message its progression will be consider INTERMEDIATE until the last Event Unit is sent as OFFICIAL. LIVE_FULL : This status is used only in real time messages. LIVE_LAST : This status is used only in real time messages. LIVE_MANDATORY : This status is used only in real time messages. LIVE_UPDATE : This status is used only in real time messages. PARTIAL : Results of the top x competitors are released at the end of a race and before all competitors finished their competition. The results including the ranking, from the competitors that finished the race do not change with the results from new competitors. OFFICIAL : Results of the competition released as soon as the event is officially confirmed taking into account the resolution of the protests, etc. UNOFFICIAL : Results of the competition released as soon as the event is over, not waiting any official decision of the International Federation. The correctness of data must be assured. |
|
|
S(8) |
Defined in ODF Common Codes Document
See entity Sport Class • The entity’s attribute to be used is Id |
|
|
S(2) |
Defined in ODF Common Codes Document
See entity Event Unit • The entity’s attribute to be used is Eventunit • It will be related to Discipline, Gender, Event and Phase |
||
S(3) |
Defined in ODF Common Codes Document
See entity Venue • The entity’s attribute to be used is Id |
||
S(3) |
Defined in ODF Common Codes Document
See entity Wind Direction • The entity’s attribute to be used is Id |
Format |
Entity Description |
|
S(2) |
LH : Large Hill NH : Normal Hill |
|
S(5) |
DNS : Did not start DSQ : Disqualified (The provided codes order is according to the sport rules. In case of several DSQ or DNS, sort by reverse order of their bib numbers). |
|
S(7) |
PQ : Prequalified Q : Qualified QR : Qualified by rule (jury decision) |
|
S(13) |
IRM : Invalid Result Mark POINTS : Points PREQUALIFIED : Pre-qualified jumpers in the Qualification, which will not get points+rank |
|
S(3) |
KMH : km/h MS : m/s |
|
S(1) |
C : Celsius F : Fahrenheit |
|
S(6) |
GEN: General |
ODF interface defines ODF messages. ODF messages are data structures based on standard XML.
<?xml version="1.0" encoding="UTF-8"?> ßDeclaration |
|||
<OdfBody DocumentType=… DocumentCode=… > |
ßODF Header |
||
[body] |
ßODF Body |
||
</OdfBody> |
|
||
The first line in an ODF message is the XML declaration. It defines the XML version and the encoding used, UTF-8.
The next line after the declaration is the ODF header.
ODF header is the root element and it is always introduced by the element Odfbody.
Header attributes identifies ODF messages uniquely.
The message unique identifier is the aggregation of the following attributes:
· DocumentCode,
· DocumentSubcode (Optional)
· DocumentType and
· DocumentSubtype (Optional)
The following table describes the ODF header attributes. “M” designates mandatory attributes that must appear in all ODF messages. “O” designates optional attributes. Optional attributes can be required depending on other attributes in the header.
Attribute |
M/O |
Value |
Comment |
DocumentCode |
M |
S(9)
|
RSC for Results messages DDGEEEPUU, where DD=discipline, G=discipline’s gender, EEE=event, P=phase, UU=unit
DocumentCode can have many different values depending on the nature of the message. Each message defines the value for this header attribute. |
DocumentSubcode |
O |
S(10) |
Extension for the DocumentCode It is used when the RSC is not enough and it is required several different messages with the same RSC. |
DocumentType |
M |
S(30) |
Message Type (e.g. DT_RESULTS) |
DocumentSubtype |
O |
S(20) |
Attribute used to extend DocumentType for some messages. |
Version |
M |
1..V |
Version of the message |
ResultStatus |
O |
CC @ResultStatus
|
Status of the messages for results message |
Language |
O |
CC @Language
|
Language of the content of the message.
If the message accepts multi-language and the attribute is not included, then by default the language is English
If the message does not accept multi-language, then the attribute must not be included |
FeedFlag |
M |
“P”-Production “T”-Test |
Test message or production message.
|
Date |
M |
Date |
Date when the message is generated, expressed in the local time zone where the message was produced. |
Time |
M |
MillisTime |
Time up to milliseconds when the message is generated, expressed in the local time zone where the message was produced. |
LogicalDate |
M |
Date |
Logical Date of events that extends until next day. If an event unit continues after midnight (24:00), all messages produced will be considered as happening at the logical date on which the event unit began (e.g. for a session which began at 21:00 on Aug 2 and ended at 1:20 on Aug 3, the output will be dated Aug 2).
The end of the logical day is defined by default at 03:00 a.m.
For messages corrections, like invalidating medals or Records, it will be the LogicalDate of the correction.
Logical Date is expressed in the local time zone where the message was produced. |
Venue |
O |
CC @VenueCode |
Venue where the message is generated. |
RTSerial |
O |
Numeric |
Sequence number for ODF-RT messages.
RTSerial starts with 1 each Real Time session at every different venue. |
Serial |
M |
Numeric |
Sequence number for ODF-PiT messages.
Serial starts with 1 each day session at every different venue.
In the case of RT transmission, this attribute contains the last PiT message Serial number in order to ensure that RT information is processed over the last PiT information. |
The next line after the ODF header is the body of the ODF Message.
Declaration |
<?xml version="1.0" encoding="UTF-8"?> |
|||||
Header |
<OdfBody DocumentType=… > |
|
||||
|
<Competition Code= …> |
ß <Competition> element |
||||
|
…. |
|||||
Body |
</Competition> |
|||||
|
<Message> Athlete nnnn disqualified… </Message> |
ß <Message> element |
||||
|
</OdfBody> |
|
||||
Some important considerations for the ODF messages:
Mandatory elements are sent always.
· Empty optional elements are not sent neither in ODF-PiT nor ODF-RT
· Mandatory attributes are sent always. If they do not have any value then they are sent empty (Attribute =”“)
· Empty optional attributes are sent either empty (Attribute = ““) or not sent.
· Order of the elements inside an ODF message must be followed as defined in the ODF documentation. Elements must be sorted according what it is stated in the corresponding ODF message definition
· All elements in an ODF message are identified by one of the attributes (e.g. Code for an Competitor element) or a set of the attributes (e.g. Type + Code for an Extension element)
· ODF is being designed in such way that elements and attributes are organized to minimize redundancy and dependency. The objective is to isolate data so that additions, deletions, and modifications of an attribute can be made with just one message and then propagated through the rest of the messages via the defined references. However, in some very special circumstances, some important information (such as team members) will be repeated in order to make some message processing a little bit easier. Also, the ODF Light definition repeats some data across messages to simplify message processing to ODF Light Customers.
· ODF Light is a set of self-contained messages with the aim of simplifying the message processing to the clients as they do not have to resolve references
An ODF message contains a mandatory element <Competition>.
Element |
Attribute |
M/O |
Value |
Comment |
Competition |
Code |
M |
CC @Competition
|
Unique ID for the competition
|
All ODF messages can have an optional element <Message> to include free non-formatted text in case more information is needed.
<Message> element follows the <Competition> element.
ODF messages contain an optional element <Competitor> to include information for Athletes, Teams or Groups. Group is used when competitors of same or different organizations participate in an event together but they are not considered a team and their results are individuals.
Element |
Attribute |
M/O |
Value |
Comment |
Competitor |
Code |
M |
S(20) with no leading zeroes |
Competitor’s ID
|
Type |
M |
T, A, G |
T = Team A = Athlete G = Group |
If Competitor is an Athlete:
· <Competitor> element contains the attribute Type = ”A”
· <Competitor> element contains the attribute Code = AthleteID. This attribute links to an athlete appearing in the DT_PARTIC message.
· <Competitor> element contains the element <Composition>. This element is provided always.
· <Composition> element contains the mandatory element <Athlete>. Both codes in the <Athlete> and in the <Competitor> elements are the same, the AthleteID
· <Athlete> element contains the mandatory attribute Order with value 1.
· Athlete’s Bib (if applicable) will be only sent in Competitor /Composition /Athlete element.
· Sport specific extensions are in the <Athlete> element and defined in the ODF Discipline Data Dictionary.
<Competitor Code= “A1” Type=”A”> |
<Composition> <Athlete Code=”A1” Order=”1”/> </Composition> |
</Competition> |
If Competitor is a Team:
· <Competitor> element contains the attribute Type =”T”
· <Competitor> element contains the attribute Code = TeamCode. This attribute links to a team appearing in the DT_PARTIC_TEAMS message.
· <Competitor> element contains the element <Composition>. This element is optional because there are situations where the team members are not known when message is provided.
· <Composition> element contains the mandatory element <Athlete> with the list of athletes that are the team members. The Code attribute links to an athlete appearing in the DT_PARTIC (athletes) message.
· Although team members for the whole event will be able to be found in the DT_PARTIC_TEAMS message, the specific ODF Sport messages will also include always the team’s members particularized for the message.
· <Athlete> element contains the mandatory attribute Order with the team members sort order.
· Team’s Bib (if applicable) will be sent in Competitor element.
· Team members’ Bib (if applicable) will be sent in Competitor /Composition /Athlete element.
· Team sport specific extensions are in the <Competitor> element and defined in the ODF Discipline Data Dictionary.
· Team members sport specific extensions are in the <Athlete> element and defined in the ODF Discipline Data Dictionary.
<Competitor Code= “T1” Type=”T”> |
<Composition> <Athlete Code=”A1” Order=…/> <Athlete Code=”A2” Order=…/> … </Composition> |
</Competition> |
If Competitor is a Group:
· <Competitor> element contains the attribute Code = NOC/NPC when the athletes belong to the same organization, otherwise MIXn.
· There will be several Competitor /Composition /Athlete elements, containing the group competitor members.
This chapter describes data types and formats for the attributes in the ODF messages.
Format |
Format Description |
CC @CodeEntity |
Set of values included in the CodeEntity. CodeEntity is the name of the entity that identifies a particular set of codes. |
String |
Text strings without a predetermined length |
S(n) |
Text strings with a length of up to n characters |
Date |
YYYYMMDD |
MillisTime |
HHMMSSmmm
All formatted with leading zeroes (example: 090303020). |
DateTime |
YYYY-MM-DDThh:mm:ssTZD (e.g.: 2006-02-06T13:00:00+01:00)
|
Boolean |
‘true’ or ‘false’ |
Numeric |
Number with no predetermined length
· If nothing is stated, it is assumed that the leading zeroes are removed |
N(n) |
Number with a length up to n digits |
N(n).N(m) |
Number with decimal
|
Specific pattern |
Attributes with an specific pattern not specified in this table |
Free text |
Free text is never used in a message attribute, but it can be used inside the element content Example <element>Free text goes in here</element> |
This chapter describes the rules for rounding numbers to use in all messages, unless other rules are specified in the sport documentation. (sport rules are applied before the transmission of the data)
· Last digit in the number decimal part < 5 (0, 1, 2, 3, 4) à no rounding (i.e. 1,544 = 1, 54)
· Last digit in the number decimal part >= 5 (5, 6, 7, 8, 9) à rounding up (i.e. 1,545 = 1, 55)
This chapter describes the measure formats and the conversion rules to use in all messages, unless other formats or rules are specified in the sport documentation.
Measure |
Value |
Format |
Example |
Height/Distance |
N(1).N(2)m N(3)cm N(1)’N(2)’’ |
9.00m 900cm 9’09’’ |
1.83m 183cm 6’0’’ |
Weight |
N(3)kg N(3)lbs |
900kg 900lbs |
100kg 220lbs |
Temperature |
N(2)ºC N(3)ºF |
90ºC 990ºF |
35ºC 95ºF |
Distance |
N(3).N(3)km N(3).N(3)mi |
90.000km 90.000m |
1.789km 6.123mi |
Speed |
N(2).N(3)m/s N(3).N(3)mph N(3).N(3)km/h |
90.000m/s 90.000mph 90.000km/h |
1.789m/s 6.123mph 3.890km/h |
Precipitation |
N(2)cm N(2)in |
90cm 90in |
2cm 1in |
This chapter describes measure the conversion rules to use in all messages, unless other rules are specified in the sport documentation. When using these conversions for athlete heights and weights and fore mentioned rounding rules must be applied.
Measure |
Conversion Rules |
Distance |
1 in = 0,0254 m 1 ft = 12 in = 0,3048 m 1 yd = 3 ft = 36 in = 0,9144 m 1 mi = 1.760 yd = 5.280 ft = 63360 in = 1609,344 m 1 nmi (nautical mile) = 1,852 m |
Speed |
1 km/h = 3,6 m/s 1 kts= 1 nmi/h |
Weight |
1 lbs = 0,453 592 37 kg |
Temperature |
T[°F] = 1,8 × T[°C] + 32 T[°C] = (T[°F] – 32) / 1.8 |
An update occurs when it is received a message whose identification is coinciding with the identification of an already received message.
Message identification is the combination of the header attributes: DocumentCode + DocumentSubcode + DocumentType + DocumentSubtype.
ODF PiT:
The latest message substitutes completely the previous received message.
There are specific messages, (with an UPDATE suffix) for updating some elements and keep the rest of the message, e.g. DT_SCHEDULE_UPDATE, DT_PARTIC_UPDATE, DT_PARTIC_TEAMS_ UPDATE or DT_PARTIC_HORSES_UPDATE.
ODF RT:
When the message header contains the attribute ResultStatus = LIVE_FULL or LIVE_LAST or LIVE_MANDATORY, the latest message substitutes completely the previous received message.
When the message header contains the attribute ResultStatus = LIVE_UPDATE, only the elements and attributes in the new message must be updated by message receiver. Elements and attributes provided before must be kept by message receiver.
· New message only includes the changed attributes, with the exception of the mandatory attributes that are always sent even if there is no modification.
When an attribute sent in the past has no value anymore, send the same message with ResultStatus=LIVE_MANDATORY and
· If the attribute is mandatory send it empty (Attribute=””)
· If the attribute is optional either do not send it or send it empty
ODF/INT016 R3 v7.6 APP (SJ)
Date |
Comments |
|
R3 v1.0 |
16 Nov 2011 |
Submitted for review version. |
R3 v1.1 |
23 Dec 2011 |
New document restructuration, including ODF light elements, and applying some Omega comments. |
R3 v1.2 |
27 Jan 2012 |
Reviewer comments included. |
R3 v2.0 |
10 Feb 2012 |
DRF comments included. |
R3 v2.1 |
02 Mar 2012 |
DRF comments included. Official type included in ExtOfficial element. |
R3 v3.0 |
05 Apr 2012 |
Pre-integration comments added. |
R3 v4.0 |
08 May 2012 |
Pre-integration phase 2 comments added. |
R3 v4.1 |
25 May 2012 |
Pre-integration phase 3 comments added. |
R3 v4.2 |
25 Jun 2012 |
Defects applied. |
R3 v5.0 |
16 Jul 2012 |
DRF comments included. |
R3 v6.0 |
23 Jul 2012 |
After WNPA meeting changes: ODF light information deletion and new messages proposal (APP-DRAFT). |
R3 v6.1 |
27 Aug 2012 |
Minor changes in the format data. |
R3 v6.2 |
28 Sept 2012 |
DRF requirements implemented. CRs applied (SFR version). |
R3 v6.3 |
11 Oct 2012 |
DRF requirements implemented. CRs applied (SFA version). |
R3 v7.0 |
14 Dec 2012 |
DRF and PT requirements implemented. |
R3 v7.1 |
31 Jan 2013 |
Defect applied. |
R3 v7.2 |
15 March 2013 |
Document generated using the CMS tool |
R3 v7.3 |
10 May 2013 |
CR applied |
R3 v7.4 |
09 August 2013 |
CR applied |
R3 v7.5 |
27 September 2013 |
CR/defects applied |
R3 v7.6 |
12 December 2013 |
CR/Defects applied |
Status |
Changes on version |
|
R3 v1.0 |
SFR |
• First version. |
R3 v1.1 |
SFR |
• See version history. |
R3 v1.2 |
SFR |
• Reviewer comments included. |
R3 v2.0 |
SFA |
• DRF comments included. |
R3 v2.1 |
SFA |
• DRF comments included. • Official type included in ExtOfficial element. |
R3 v3.0 |
SFA |
• The ‘General’ CC @ResultType will be used also for the Team trial event, when the result will came at the athlete level. • Compensation points information updated • SJ_JUMP_ORDER and SJ_IDX_ORDER removed from the athlete extended results. • SJ_LAST_QUALIFIED field added in the DT Result message in the UnitInfos /UnitInfo Element. • New fields added Rank and Erank in the Result / Competitor / Composition /Athlete /ExtendedResults /ExtendedResul element • Start List trigger updated. |
R3 v4.0 |
SFA |
• Defects 72446, 72209, 72542 applied: RT Results and RT results Summary triggers updated. Result (CummulativeResult)/SortOrder definition updated. • DRF 1 (26 April 2012): Pos defined for the DT Results UnitInfos /UnitInfo/SJ_BASE_GATE. • Defect 71777: SJ_GATE_FACTOR from the DT_CONFIG used with @Pos. |
R3 v4.1 |
SFA |
• SJ_LAST_QUALIFIED field updated in the DT Result message in the UnitInfos /UnitInfo Element. • SJ_GATE_FACTOR from the DT_CONFIG used without @Pos. • Defect 76172 applied: SJ_IDX_ORDER attribute added in the Athlete extension of the Result message, only for the team trial event. |
R3 v4.2 |
SFA |
• Defect 77018 applied: SJ_JUMP_POINTS and SJ_TANG_WIND attributes’ value updated. Negative values allowed. |
R3 v5.0 |
APP |
• DRF comments included. • RegisteredEvent element of the DT_PARTIC message updated with the general description. • RegisteredEvent element of the DT_PARTIC_TEAMS message updated with the general description. • Bib value updated. • DT_CONFIG: SJ_GATE_NUMBER defined as S(5). • DT_RANKING: Result/Competitor element updated. • SJ_LAST_QUALIFIED defined as RT only. • DT_STARTLIST: SJ_IDX_ORDER code removed. • DT_HIST_REC_UPDATE message added in the 5.1 chapter. • DT_(RT)_RESULT: SJ_RANK and SJ_ERANK explanation updated in the competitor extension. • DT_(RT)_RESULT: for the code SJ_IRF, the RT Only set to N. • DT_(RT)_RESULT: SJ_LENGTH_POINTS set with negative values, SJ_JUMP_POINTS set only with positive values. • The messages’ structure file updated. |
R3 v6.0 |
APP (DRAFT) |
• New messages proposal: Added the definition of DT_CUMULATIVE_RESULT and DT_RT_CUMULATIVE_RESULT messages (marked in blue color). These messages should be used (instead of DT_RESULT_SUMMARY and DT_RT_RESULT_SUMMARY) at the moment that these changes are approved until then the deprecated messages should be still used. • Deletion messages proposal: DT_RESULT_SUMMARY and DT_RT_RESULT_SUMMARY (marked in pink color). These messages should be deleted at the moment that these changes are approved until then the deprecated messages should be still used. • Deletion extensions proposal: ODF Light extensions from the DT_START_LIST Message. Marked in pink color the ODF Light extensions. These extensions should be deleted at the moment that these changes are approved until then they should be still used. |
R3 v6.1 |
APP (DRAFT) |
• Minor changes in the format data in green. • DT_Weather message updated. |
R3 v6.2 |
SFR |
• Light extension: ODF Light extensions from the DT_START_LIST, DT_CUMULATIVE_RESULT and DT_PHASE_RESULT messages marked in pink colour. These extensions will be deleted at the moment that these changes are implemented by Omega for Non-Olympics projects from those messages and included in new messages. • Light Extensions: DT_START_LIST PreviousResults defined as non-light extension. • New messages: Added the definition of DT_PHASE_RESULT, DT_CUMULATIVE_RESULT and DT_RT_PHASE_RESULT, DT_RT_CUMULATIVE_RESULT messages. These messages should be used (instead of DT_RESULT_SUMMARY and DT_RT_RESULT_SUMMARY). • DT_EXTRA_DATA renamed to DT_PLAY_BY_PLAY. • DT_RT_EXTRA_DATA renamed to DT_RT_PLAY_BY_PLAY. • DT_CUMULATIVE_RESULT, DT_RT_CUMULATIVE_RESULT, DT_RESULT and DT_RT_RESULT messages structure merged: - CumulativeResults element of the DT_CUMULATIVE_RESULT/RT renamed to Results. - Bib attribute added to Competitor and Athlete element of the DT_CUMULATIVE_RESULT,DT_RT_CUMULATIVE_RESULT messages. • SortOrder attribute clarified so that any resultsort order change from the initial start list order will be provided in the SortOrder attribute (or any extension used to sort competitors) of the DT_RT_RESULT message (this includes ranked, none-ranked and IRM athletes/team). |
R3 v6.3 |
SFA |
• CR203 applied: RankEqual Results attribute is optional. • Team’s SJ_RANK explained in more detail. • Athlete’s SJ_RANK explained in more detail. • Pos removed from the SJ_LAST_FINISHED code. • ResultType DISTANCE removed. • ResultType is optional. • DT_RESULT message. EndDate attribute set to Optional. • SortOrder of the Cumulative message updated. • Bib removed from the DT_PARTIC message. • UnitAction @Time removed as sort option for the Result message. • Rank, RankEqual, IRM, Result set to optional for the DT_Ranking message. • StartDate code of the UnitDateTime element from the Result message is optional. • SJ_IDX_ORDER explanation updated. • PreviousResults sent only in case of individual competitions final round. • PreviousResults sent only in case of team competitions final round. |
R3 v7.0 |
APP |
• ResultType General removed from the Ski Jumping codes. • Start List trigger updated with the Live Mandatory message requirement. |
R3 v7.1 |
APP |
• SJ_LAST_QUALIFIED not only RT. The field is required to fill the leader board of the screens (defect 87079 applied). |
R3 v7.2 |
APP |
Document generated using the CMS tool |
R3 v7.3 |
APP |
CR322 applied: ResultType 'Points_IRM' removed from the sport codes list |
R3 v7.4 |
APP |
CR000948 applied: SJ_LAST_QUALIFIED code defined as the last qualifyed athlete (defect 94524) CR666 applied: Added Venue attribute as mandatory for DT_PARTIC / DT_PARTIC_UPDATE and DT_PARTIC_TEAMS_UPDATE / DT_PARTIC_TEAMS messages. CR906 applied: Removed ODF Light elements from DT_START_LIST message. CR974 applied: Remove "+" symbol in weather attributes, when sending values above 0 degrees. Change applies to DT_WEATHER message. CR985 applied: ODF DT_WEATHER message changes: -Weather /Conditions@Code the value should use CC @WeatherPoints - the code Weather /Conditions /Temperature@Type removed -CC @WeatherPoints defined with 'General' value. -CC @TemperatureUnit defined in the SJ codes CR001009 applied: SJ_COMP_GATE should define "0.0" value instead of "00.0" SJ_COMP_WIND should define "0.0" value instead of "00.0" SJ_COMP_TOTAL should define "0.0" value instead of "00.0" |
R3 v7.5 |
APP |
CR001220 applied: the definition of the "ER_SJ/SJ_GROUP/SJ_RANK" and "ER_SJ/SJ_GROUPR"/"SJ_ERANK" attributes updated. Codes not used in the case of IRM.
CR001268/Defect 96846 applied: ER_SJ/ SJ_JUMP_FINISHED code added for the T3 trigger.
CR001266 applied: Defect 97292: Unofficial (ResultStatus) status not used for trainings and trials. |
R3 v7.6 |
APP |
Defect 100811 applied: Weather /Conditions /Temperature@Unit and Weather /Conditions /Temperature@Value 'coments updated to to "Temperature in Celsius and Fahrenheit".
CR001564 applied: 1) DT_WEATHER: Weather /Conditions /Condition@Value defined as CC @WeatherConditions for SKY Conditions and as CC @SnowConditions for SNOW conditions 2) DT_WEATHER: Weather /Conditions /Wind@Value defined as N(3).N(1) without plus/minus symbols 3) DT_WEATHER: Weather /Conditions@Wind_Direction value defined as CC @WindDirection without possibility of being N(3)
CR001688 applied: Defect 97670 – small clarification in the definition of the SJ_Current code Defect 97914 – small correction in the triggering of the ER_SJ/ SJ_GROUP codes (T7 to be used instead of T6). Defect 97982 – small update in the definition of the SJ_COMP_GATE code: should be empty in case base gate. |
This page has been intentionally left blank