Table of content

Table of content 3

1   Introduction   6

1.1.. This document 6

1.2.. Objective. 6

1.3.. Main Audience. 6

1.4.. Glossary. 6

1.5.. Related Documents. 8

2   Overall Perspective  9

2.1.. Objective. 9

2.2.. End to End data flow. 9

3   Messages  10

3.1.. Applicable Messages. 10

3.2.. Messages. 12

3.2.1... List of participants by discipline / List of participants by discipline Update. 12

3.2.1.1    Description. 12

3.2.1.2    Header Values. 12

3.2.1.2.1     PiT Header 12

3.2.1.3    Trigger and Frequency. 13

3.2.1.3.1     PiT Triggers. 13

3.2.1.4    Message Structure. 14

3.2.1.5    Message Values. 16

3.2.1.6    Message Sort 18

3.2.2... Start List 19

3.2.2.1    Description. 19

3.2.2.2    Header Values. 19

3.2.2.2.1     PiT Header 19

3.2.2.3    Trigger and Frequency. 20

3.2.2.3.1     PiT Triggers. 20

3.2.2.4    Message Structure. 21

3.2.2.5    Message Values. 22

3.2.2.6    Message Sort 24

3.2.3... Event Unit Results. 25

3.2.3.1    Description. 25

3.2.3.2    Header Values. 25

3.2.3.2.1     PiT Header 25

3.2.3.2.2     RT Header 26

3.2.3.3    Trigger and Frequency. 27

3.2.3.3.1     PiT Triggers. 27

3.2.3.3.2     RT Triggers. 27

3.2.3.4    Message Structure. 28

3.2.3.5    Message Values. 30

3.2.3.6    Message Sort 39

3.2.4... Cumulative Results. 40

3.2.4.1    Description. 40

3.2.4.2    Header Values. 40

3.2.4.2.1     PiT Header 40

3.2.4.2.2     RT Header 41

3.2.4.3    Trigger and Frequency. 42

3.2.4.3.1     PiT Triggers. 42

3.2.4.3.2     RT Triggers. 43

3.2.4.4    Message Structure. 45

3.2.4.5    Message Values. 47

3.2.4.6    Message Sort 49

3.2.5... Event Final Ranking. 50

3.2.5.1    Description. 50

3.2.5.2    Header Values. 50

3.2.5.2.1     PiT Header 50

3.2.5.3    Trigger and Frequency. 51

3.2.5.3.1     PiT Triggers. 51

3.2.5.4    Message Structure. 52

3.2.5.5    Message Values. 53

3.2.5.6    Message Sort 54

3.2.6... Event’s Medallists. 55

3.2.6.1    Description. 55

3.2.6.2    Header Values. 55

3.2.6.2.1     PiT Header 55

3.2.6.3    Trigger and Frequency. 56

3.2.6.3.1     PiT Triggers. 56

3.2.6.4    Message Structure. 57

3.2.6.5    Message Values. 58

3.2.6.6    Message Sort 58

3.2.7... Discipline Configuration. 59

3.2.7.1    Description. 59

3.2.7.2    Header Values. 59

3.2.7.2.1     PiT Header 59

3.2.7.3    Trigger and Frequency. 60

3.2.7.3.1     PiT Triggers. 60

3.2.7.4    Message Structure. 61

3.2.7.5    Message Values. 62

3.2.7.6    Message Sort 64

3.2.8... Event Unit Weather Conditions. 65

3.2.8.1    Description. 65

3.2.8.2    Header Values. 65

3.2.8.2.1     PiT Header 65

3.2.8.3    Trigger and Frequency. 65

3.2.8.3.1     PiT Triggers. 65

3.2.8.4    Message Structure. 67

3.2.8.5    Message Values. 68

3.2.8.6    Message Sort 68

4   Messages Sequence  71

5   Codes  72

5.1.. Global Codes. 72

5.2.. Skeleton Codes. 74

6   General definitions  76

6.1.. ODF Message Structure. 76

6.1.1... ODF Declaration. 76

6.1.2... ODF Header 76

6.1.3... ODF Body. 78

6.2.. ODF Data Types and Formats. 81

6.2.1... Rules for rounding numbers. 82

6.2.2... Measures format 83

6.2.3... Rules for measures conversion. 83

6.3.. ODF Message Update. 84

7   DOCUMENT CONTROL   86

7.1.. File Reference. 86

7.2.. Version history. 86

7.3.. Change Log. 87

 

1   Introduction

1.1  This document

This document includes the ODF Skeleton Data Dictionary. This document refines the messages described in the ODF General Messages Interface Document specifically for Skeleton, as well as defines the codes used in these messages.

1.2  Objective

The objective of this document is to provide a complete and formal definition of the ODF Skeleton Data Dictionary, with the intention that the information message producer and the message consumer can successfully interchange the information as the Skeleton competition is run.

1.3  Main Audience

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.

1.4  Glossary

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

RSC

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

 

 

 


 

1.5  Related Documents

 

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

 

 

2   Overall Perspective

2.1  Objective

The objective of this document is to focus on the formal definition of the ODF Skeleton Data Dictionary.

2.2  End to End data flow

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.


3   Messages

3.1  Applicable Messages

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 Type

Message Name

Feed

Message extended

DT_SCHEDULE

Competition schedule

PiT

 

DT_SCHEDULE_UPDATE

Competition schedule update

PiT

 

DT_PARTIC / DT_PARTIC_UPDATE

List of participants by discipline / List of participants by discipline Update

PiT

X

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_START_LIST

Start List

PiT

X

DT_RESULT

Event Unit Results

PiT/RT

X

DT_CUMULATIVE_RESULT

Cumulative Results

PiT/RT

X

DT_RANKING

Event Final Ranking

PiT

X

DT_MEDALLISTS

Event’s Medallists

PiT

X

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_CONFIG

Discipline Configuration

PiT

X

DT_WEATHER

Event Unit Weather Conditions

PiT

X

DT_SERIAL

List of Current PiT Serial

PiT

 

DT_RT_KA

RT Discipline/Venue keep alive

RT

 

DT_PDF

PDF Message

PDF

 

DT_PDF_GM

PDF Discipline/Venue good morning

PDF

 

DT_PDF_GN

PDF Discipline/Venue good night

PDF

 

DT_PDF_SERIAL

List of Current PDF Serial

PDF

 

DT_RT_GM

RT Discipline/venue good morning

RT

 

DT_RT_GN

RT Discipline/venue good night

RT

 

 

 

 

 


 

3.2  Messages

 

3.2.1    List of participants by discipline / List of participants by discipline Update

3.2.1.1  Description

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.

 

 

3.2.1.2  Header Values

3.2.1.2.1  PiT Header

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

CC @VenueCode

Venue where the message is generated.

 

 

3.2.1.3  Trigger and Frequency

3.2.1.3.1  PiT Triggers

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.

 

 


3.2.1.4  Message Structure

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

 

 

 

 

Bib

 


3.2.1.5  Message Values

Competition

Attribute

M/O

Value

Comments

Code

M

CC @Competition

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

CC @AccreditationStatus

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

CC @PersonGender

Participant’s gender

Organisation

M

CC @Organisation

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

CC @Country

Country ID of Birth

PlaceofResidence

O

S(75)

Place of Residence

CountryofResidence

O

CC @Country

Country ID of Residence

Nationality

O

CC @Country

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

CC @Function

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 to 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

CC @Discipline

It is the discipline code used to fill the OdfBody @DocumentCode attribute.

InternationalFederationId

O

S(16)

Competitor’s federation number for the corresponding discipline (include if the discipline assigns international federation codes to athletes).

 

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

CC @DisciplineGender

Discipline Gender Code

Event

M

CC @Event

Event ID

Bib

O

Bib number.

Bib number.

 

Bib number is in fact a special Event Entry. However, since it is very meaningful in the sports that make use of this attribute, it has been considered as an attribute, although it was part of EventEntry in the previous versions.

Send only in the Case of Current=”true”.

 

 

3.2.1.6  Message Sort

The message is sorted by Participant @Code


 

 

3.2.2    Start List

3.2.2.1  Description

The start list is a message containing the list of competitors for one particular event unit as single athletes or as aggregated athletes.

 

The start list is a generic message for all sports, including as much generic information as possible, considering start lists may have substantial differences between different disciplines and events (example: mass start list, line-ups, etc.).

 

 

3.2.2.2  Header Values

3.2.2.2.1  PiT Header

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

CC @VenueCode

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

 

 

3.2.2.3  Trigger and Frequency

3.2.2.3.1  PiT Triggers

As general rule, the message is sent as soon as the expected information is available:

-  event unit related information (PhaseInfos, UnitInfos, and Officials)

-  event unit related competitors.

 

Trigger also after any major change.

 

 


3.2.2.4  Message Structure

Following table defines the structure of the message.

Level 1

Level 2

Level 3

Level 4

Level 5

Level 6

Competition

 

 

 

 

 

 

Code

 

 

 

 

 

UnitInfos (0,1)

 

 

 

 

 

 

UnitDateTime (0,1)

 

 

 

 

 

 

StartDate

 

 

 

 

UnitInfo (0,N)

 

 

 

 

 

 

Type

 

 

 

 

 

Code

 

 

 

 

 

Pos

 

 

 

 

 

Value

 

 

 

Officials (0,1)

 

 

 

 

 

 

Official (1,N)

 

 

 

 

 

 

Code

 

 

 

 

 

Function

 

 

 

 

 

Order

 

 

 

Start (0,N)

 

 

 

 

 

 

StartOrder

 

 

 

 

 

SortOrder

 

 

 

 

 

Competitor

 

 

 

 

 

 

Code

 

 

 

 

 

Type

 

 

 

 

 

Composition (0,1)

 

 

 

 

 

 

Athlete (1,N)

 

 

 

 

 

 

Code

 

 

 

 

 

Order

 

 

 

 

 

Bib

 


3.2.2.5  Message Values

Competition

Attribute

M/O

Value

Comments

Code

M

CC @Competition

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.

 

UnitInfos /UnitInfo

Unit info item associated to the event unit.

Type

Code

Pos

Value

Description

UI_SN

SN_HEAT_NUMBER

 

N(2) 99

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Value:

Heat number

SN_ START_RECORD_TIME

 

MM:SS.hh

99:90.00

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Value:

Start time record of track

MM is minutes, SS is seconds, hh is hundredth of second

SN_START_RECORD_PARTIC

 

S(20)

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Value:

Competitor ID record owner, with no leading zeroes,

SN_START_RECORD_DATE

 

N(8)

YYYYMMDD

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Value:

Date of record

SN_TRACK_RECORD_TIME

 

MM:SS.hh

99:90.00

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Value:

Heat time record of track

MM is minutes, SS is seconds, hh is hundredth of second

SN_TRACK_RECORD_PARTIC

 

S(20)

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Value:

Competitor ID record owner, with no leading zeroes,

SN_TRACK_RECORD_DATE

 

N(8)

YYYYMMDD

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Value:

Date of record

 

For the table above, we have the following additional/summary information:

 

Type/Code

Description

Expected

UI_SN/ SN_HEAT_NUMBER

Heat number

Always

UI_SN/ SN_ START_RECORD_TIME

Start time Track Record

Always

UI_SN/ SN_START_RECORD_PARTIC

Competitor’s ID

Always

UI_SN/ SN_START_RECORD_DATE

Record Date

Always

UI_SN/ SN_TRACK_RECORD_TIME

Time Track Record

Always

UI_SN/ SN_TRACK_RECORD_PARTIC

Competitor’s ID

Always

UI_SN/ SN_TRACK_RECORD_DATE

Record Date

Always

 

 

 

Officials /Official

Official associated to the event unit.

Attribute

M/O

Value

Comments

Code

M

S(20) with no leading zeroes

Official’s code

Function

M

CC @Function

Official’s function (example: referee, etc.).

 

Can be different from the function sent in the DT_PARTIC message.

Order

O

Numeric

Official’s order (if the discipline specificity required it).

 

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

O

Numeric

Competitor’s start order

SortOrder

M

Numeric

Used to sort all start list competitors in an event unit (for example, when the StartOrder is missing).

 

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

A

A for athlete

 

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

N/A

Bib

M

N(3)

990

Individual athlete’s bib number

 

 

3.2.2.6  Message Sort

The message is sorted by the Start@SortOrder attribute.


 

 

3.2.3    Event Unit Results

3.2.3.1  Description

The Event Unit Results is a message containing the results for the list of competitors in one event unit, either competing as single athletes or as aggregated athletes according to the team definition as it can be seen in the List of teams’ message in the ODF General Messages Interface Document.

 

The Event Unit Results message is a generic message for all sports, including as much generic information as possible, considering results may have substantial differences between different disciplines and events (example: score of a match, time in a race, distance in a throw, etc.).

 

 

3.2.3.2  Header Values

3.2.3.2.1  PiT Header

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_RESULT

Event Unit Results message

ResultStatus

CC @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

CC @VenueCode

Venue where the message is generated.

DocumentSubtype

N/A

Not used in SN.

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

 

3.2.3.2.2  RT Header

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

CC @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

CC @VenueCode

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

 

 

3.2.3.3  Trigger and Frequency

3.2.3.3.1  PiT Triggers

The general rule is that this message is sent as when the event unit finishes and the message becomes unofficial, and also afterwards when the message becomes official (when the event unit becomes official). The official/unofficial status can be seen in ODF headers (ResultStatus attribute).

 

Trigger also after any major change.

 

 

3.2.3.3.2  RT Triggers

• For ResultStatus=“LIVE_UPDATE”

o T1: Trigger after any correction of a competitor’s result.

 

o T2: Trigger when a competitor crosses an intermediate point.

 

o T3: Trigger when a competitor arrives to finish.

 

o T4: Trigger when an event unit starts.

 

o T5: Trigger to update traffic light(green/red).

 

o T6: Trigger when competitor mark his top speed.

 

o T7: Trigger when a track record must be updated

 

•  For ResultStatus=“LIVE_FULL”

o This value should be suggested after further testing and sent in the DT_RT_GM message after further testing

 

 


3.2.3.4  Message Structure

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

 

 

 

 

 

 

 

Composition

 

 

 

 

 

 

 

 

Athlete (1,N)

 

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

Order

 

 

 

 

 

 

 

Bib

 

 

 

 

 

 

 

ExtendedResults (0,1)

 

 

 

 

 

 

 

 

ExtendedResult (1,N)

 

 

 

 

 

 

 

 

Type

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

Pos

 

 

 

 

 

 

 

Value

 


3.2.3.5  Message Values

Competition

Attribute

M/O

Value

Comments

RT Only

RT Trigger

Code

M

CC @Competition

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

M

DateTime

Actual start date-time. For multi-day units, the start date-time is on the first day.

 

Not needed for Real Time.

N

When available

EndDate

O

DateTime

Actual end date-time (The attribute should be informed, when available, for ResultStatus UNOFFICIAL and OFFICIAL)

 

Not needed for Real Time.

N

When available

 

UnitInfos /UnitInfo

Unit info item associated to the event unit.

Type

Code

Pos

Value

Description

UI_SN

SN_ATTENDANCE

 

N(6)

999999

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Value:

Number of spectators

SN_START_IND

 

N(1)

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Value:

0 for Red Start Indicator,

1 for Green Start Indicator

SN_START_RECORD_TIME

 

MM:SS.hh

99:90.00

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Value:

Start time record of track

MM is minutes, SS is seconds, hh is hundredth of second

SN_START_RECORD_PARTIC

 

S(20)

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Value:

Competitor ID record owner, with no leading zeroes,

TBD, Code

SN_START_RECORD_DATE

 

N(8)

YYYYMMDD

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Value:

Date of record

SN_START_RECORD_NEW

 

S(1)

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Value:

Send “Y” when START_RECORD values are a new record acquired, otherwise send “N”

SN_TRACK_RECORD_TIME

 

MM:SS.hh

99:90.00

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Value:

Heat time record of track

MM is minutes, SS is seconds, hh is hundredth of second

SN_TRACK_RECORD_ PARTIC

 

S(20)

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Value:

Competitor ID record owner, with no leading zeroes,

TBD, Code

SN_TRACK_RECORD_DATE

 

N(8)

YYYYMMDD

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Value:

Date of record

SN_TRACK_RECORD_NEW

 

S(1)

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Value:

Send “Y” when TRACK_RECORD values are a new record acquired, otherwise send “N”

 

For the table above, we have the following additional/summary information:

 

Type/Code

Description

Expected

RT Only

RT Trigger

UI_SN/ SN_ATTENDANCE

Number of spectators

Always, as soon as this information is available

Use only in Point in time messages

N

T4

UI_SN/ SN_START_IND

Start Indicator switch, for green/red light indicator

Always, every time indicator must be changed (for RT messages)

Y

T5

UI_SN/ SN_START_RECORD_TIME

Start time Track Record

Send when Start Record must be updated

N

T7

UI_SN/ SN_START_RECORD_PARTIC

Competitor’s ID

Send when Start Record must be updated

N

T7

UI_SN/ SN_START_RECORD_DATE

N/A

Send when Start Record must be updated

N

T7

UI_SN/ SN_START_RECORD_NEW

Flag to know if record values are a new record

Send when Start Record values must be updated

N

T7

UI_SN/ SN_TRACK_RECORD_TIME

Time Track Record

Send when Heat Record must be updated

N

T7

UI_SN/ SN_TRACK_RECORD_ PARTIC

Competitor’s ID

Send when Heat Record must be updated

N

T7

UI_SN/ SN_TRACK_RECORD_DATE

Record Date

Send when Heat Record must be updated

N

T7

UI_SN/ SN_TRACK_RECORD_NEW

Flag to know if record values are a new record

Send when Heat Record must be updated

N

T7

 

 

 

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 after the current event unit This attribute is optional because the competitor could get an invalid rank mark.

N

T1,T2,T3, T4

RankEqual

O

Y or N

It identifies if a rank has been equalled.

 

For Pit, send just ‘Y’ for equalled ranks.

N

T1,T2,T3, T4

Result

O

MM:SS.hh

99:90.00

Result after the current event unit.

 

Send just in the case @ResultType is Time

 

MM is minutes, SS is seconds, hh is hundredth of second

N

T1,T2,T3, T4

IRM

O

CC @IRM

IRM for the particular event unit

 

Send just in the case @ResultType is IRM (see codes section)

N

T1,T2,T3, T4

QualificationMark

O

CC @QualificationMark

The code which gives an indication on the qualification of the competitor for the last heat of the competition (when there are 4 heats it should be informed in heat 3)

N

T1, T3

SortOrder

M

Numeric

Used to sort all the results of an  event unit

 

For Real Time this attribute is optional. Do not inform when the ResultType is empty.

 

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

T1,T2,T3, T4

ResultType

O

CC @ResultType

Type of the @Result attribute.

 

In Real Time, when the ResultType attribute is sent empty that means that the Result element is not used. The message is used just to include some extended results for a particular kind of competitor.

 

On the contrary, if ResultType is informed, and the other attributes are blank (‘’‘’), it is assumed that these attributes are being reset.

N

T1,T2,T3, 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 or TBD in case that the competitor is unknown

N

Only if necessary

Type

M

T,A

T for team

A for athlete

N

Only if necessary

 

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

Only if necessary

Order

M

Numeric

1

N

T1,T2,T3,T6

Bib

M

Bib number

Bib number

N

T1,T2,T3,T6

 

Result /Competitor /Composition /Athlete /ExtendedResults /ExtendedResult

Team member or individual athlete’s extended result.

Type

Code

Pos

Value

Description

ER_SN

SN_DIFF

Numeric

+MM:SS.hh

+99:90.00

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Pos:

Incremental number from 1 to N, to identify  each one of the splits (intervals)

- For @Value:

Time difference for the current event unit (for Result @Rank=1, send 0.00)

MM is minutes, SS is seconds, hh is hundredth of second

 

 

MM=minutes

SS=seconds

hh=hundredth of second

SN_DIFF_CURR

Numeric

+MM:SS.hh

+99:90.00

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Pos:

Incremental number from 1 to N, to identify  each one of the splits (intervals)

- For @Value:

Time difference for the current event unit for current sled display - This field always will show the difference between current sled and the leader (before the current sled!). I.e. if the current sled becomes the new leader this will stay negative and not turn to 0.00 at the finish.

MM is minutes, SS is seconds, hh is hundredth of second

SN_SPLIT

Numeric

+MM:SS.hh

+99:90.00

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Pos:

Incremental number from 1 to N, to identify  each one of the splits (intervals)

- For @Value:

time up to the split for the current event unit

MM is minutes, SS is seconds, hh is hundredth of second

SN_RANK

Numeric

Numeric

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Pos:

Incremental number from 1 to N, to identify  each one of the splits (intervals)

- For @Value:

Rank of the competitor at the moment of the split, according to its split time for the current event unit

SN_ERANK

Numeric

S(1)

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Pos:

Incremental number from 1 to N, to identify  each one of the splits (intervals)

- For @Value:

It identifies if the rank at this point has been equalled, send “Y” in this case.

SN_DIFF_TOTAL

Numeric

+MM:SS.hh

+99:90.00

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Pos:

Incremental number from 1 to N, to identify  each one of the splits (intervals)

- For @Value:

Overall Time difference (including previous heats) (for Result @Rank=1, send 0.00)

MM is minutes, SS is seconds, hh is hundredth of second

SN_DIFF_TOTAL_CURR

Numeric

+MM:SS.hh

+99:90.00

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Pos:

Incremental number from 1 to N, to identify  each one of the splits (intervals)

- For @Value:

Overall Time difference for the current event unit for current sled display - This field always will show the difference between current sled and the leader (before the current sled!). I.e. if the current sled becomes the new leader this will stay negative and not turn to 0.00 at the finish

MM is minutes, SS is seconds, hh is hundredth of second

SN_SPLIT_TOTAL

Numeric

MM:SS.hh

99:90.00

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Pos:

Incremental number from 1 to N, to identify  each one of the splits (intervals)

- For @Value:

Overall Cumulative time up to the split (including previous heats) MM is minutes, SS is seconds, hh is hundredth of second

SN_RANK_TOTAL

Numeric

Numeric

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Pos:

Incremental number from 1 to N, to identify  each one of the splits (intervals)

- For @Value:

Overall Rank of the competitor at the moment of the split, according to its split time (including previous heats)

SN_ERANK_TOTAL

Numeric

S(1)

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Pos:

Incremental number from 1 to N, to identify  each one of the splits (intervals)

- For @Value:

It identifies if the Total rank at this point has been equalled, send “Y” in this case.

SN_CURRENT

 

S(1)

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Pos:

Do not send anything

- For @Value:

Send “Y” for the current competitor, N if it is not anymore.

SN_NEXT

 

S(1)

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Pos:

Do not send anything

- For @Value:

Send “Y” for the next competitor, “N” in other case

SN_RECENT

 

S(1)

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Pos:

Do not send anything

- For @Value:

Send “Y” if this competitor is the most recent, “N” in other case.

SN_START_RECORD

 

S(1)

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Pos:

Do not send anything

- For @Value:

Send “Y” if the start_time is the actual record of the track, “N” in other case.

SN_SPEED

Numeric

N(3).N(1)

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Pos:

Incremental number from 1 to n, to identify

the split that is nearest to the speed measurement

- For @Value:

Send the measured speed in km/h

SN_SPEED_RECORD

Numeric

S(1)

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Pos:

Incremental number from 1 to n, to identify

the split that is nearest to the speed measurement

- For @Value:

Send “Y” if the SN_SPEED value is the maximum speed recorded of the track, “N” in other case.

SN_TIME_RECORD

 

S(1)

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Pos:

Do not send anything

- For @Value:

Send “Y” if the Total time is the actual record of the track, “N” in other case.

SN_BEST_START

 

MM:SS.hh

99:90.00

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Pos:

Do not send anything

- For @Value:

The best START_TIME  of participant in the track. MM is minutes, SS is seconds, hh is hundredth of second

SN_BEST_START_RECORD

 

S(1)

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Pos:

Do not send anything

- For @Value:

Send “Y” if the SN_BEST_START value is the best STAR_RECORD in the track, “N” in other case.

SN_BEST_SPEED

 

N(3).N(1)

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Pos:

Do not send anything

- For @Value:

The maximum speed recorded by the participant in the track in km/h.

SN_BEST_SPEED_RECORD

 

S(1)

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Pos:

Do not send anything

- For @Value:

Send “Y” if the SN_BEST_SPEED value is the maximum speed recorded in the track by any participant, “N” in other case.

 

For the table above, we have the following additional/summary information:

 

Type/Code

Description

Expected

RT Only

RT Trigger

ER_SN/ SN_DIFF

Time difference

Always

N

T1,T2,T3

ER_SN/ SN_DIFF_CURR

Time difference for the current event unit for current sled display - This field always will show the difference between current sled and the leader (before the current sled!). I.e. if the current sled becomes the new leader this will stay negative and not turn to 0.00 at the finish

Always

Y

T1,T2,T3

ER_SN/ SN_SPLIT

Cumulative time up to the interval

Always, if there are intervals

N

T1,T2,T3

ER_SN/ SN_RANK

Rank of the competitor at the moment of the interval

Always, if there are intervals

N

T1,T2,T3

ER_SN/ SN_ERANK

For Identifies if Rank of the competitor has been equaled

Always, if there are intervals

N

T1,T2,T3

ER_SN/ SN_DIFF_TOTAL

Overall Time difference

Always

N

T1,T2,T3

ER_SN/ SN_DIFF_TOTAL_CURR

Overall Cumulative Time difference for the current event unit for current sled display - This field always will show the difference between current sled and the leader (before the current sled!). I.e. if the current sled becomes the new leader this will stay negative and not turn to 0.00 at the finish

Always, if there are intervals

Y

T1,T2,T3

ER_SN/ SN_SPLIT_TOTAL

Overall Cumulative time up to the interval

Always, if there are intervals

N

T1,T2,T3

ER_SN/ SN_RANK_TOTAL

Overall Rank of the competitor at the moment of the interval

Always, if there are intervals

N

T1,T2,T3

ER_SN/ SN_ERANK_TOTAL

For Identifies if Rank of the competitor has been equaled

Always, if there are intervals

N

T1,T2,T3

ER_SN/ SN_CURRENT

Send “Y” for the current competitor, N if it is not anymore.

Always

Y

T1,T2,T3, T6

ER_SN/ SN_NEXT

Send “Y” for the next competitor, N if it is not anymore.

Always

Y

T1,T2,T3, T6

ER_SN/ SN_RECENT

Send “Y” for the current competitor, N if it is not anymore.

Always

Y

T1,T2,T3, T6

ER_SN/ SN_START_RECORD

Send “Y” if SN_SPLIT (Pos=1) is the best time of the track, N in other case.

Always

N

T1,T2

ER_SN/ SN_SPEED

Measured speed in an intermediate point

Always

N

T1,T6

ER_SN/ SN_SPEED_RECORD

Send “Y” if SN_SPEED is the maximum speed recorded in the track.

Always

N

T1,T6

ER_SN/ SN_TIME_RECORD

Send “Y” if SN_SPLIT (Last Pos) is the best time of the track, N in other case.

Always

N

T1,T3

ER_SN/ SN_BEST_START

The best START_TIME  of participant in the track.

Always

N

T1,T2,T3

ER_SN/ SN_BEST_START_RECORD

Send “Y” if the SN_BEST_START value is the best STAR_RECORD in the track, “N” in other case.

Always

N

T1,T2,T3

ER_SN/ SN_BEST_SPEED

The maximum speed recorded by the  participant in the track.

Always

N

T1,T2,T3,T6

ER_SN/ SN_BEST_SPEED_RECORD

Send “Y” if the SN_BEST_SPEED value is the maximum speed recorded in the track by any participant, “N” in other case.

Always

N

T1,T2,T3,T6

 

 

 

 

3.2.3.6  Message Sort

Sort by Result @SortOrder


 

 

3.2.4    Cumulative Results

3.2.4.1  Description

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.

 

 

3.2.4.2  Header Values

3.2.4.2.1  PiT Header

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

CC @ResultStatus

It indicates whether the result is official or unofficial.

“OFFICIAL” /

“UNOFFICIAL”

DocumentSubtype

DDGEEEPUU

It is the DocumentCode 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

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

CC @VenueCode

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

 

3.2.4.2.2  RT Header

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 @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

CC @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

CC @VenueCode

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

 

 

3.2.4.3  Trigger and Frequency

3.2.4.3.1  PiT Triggers

The general rule is that this message is sent as soon as:

 

 If results are accumulating across 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 unofficial:

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.

 

Don’t send this message for trainings

 

 

3.2.4.3.2  RT Triggers

• For ResultStatus=“LIVE_UPDATE”:

 

o T3: Trigger when a competitor arrives to finish.

 

•  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)).

 

Don´t send this message for trainings

 

 


3.2.4.4  Message Structure

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

 

 

 

 

 

 

 

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

 

 

 

 

 

 

 

Composition

 

 

 

 

 

 

 

 

Athlete (1,N)

 

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

Order

 

 

 

 

 

 

 

Bib

 

 

 

 

 

 

 

ExtendedResults (0,1)

 

 

 

 

 

 

 

 

ExtendedResult (1,N)

 

 

 

 

 

 

 

 

Type

 

 

 

 

 

 

 

Code

 

 

 

 

 

 

 

Pos

 

 

 

 

 

 

 

Value

 


3.2.4.5  Message Values

Competition

Attribute

M/O

Value

Comments

RT Only

RT Trigger

Code

M

CC @Competition

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

Text

Rank of the competitor in the cumulative result

N

Only if necessary

RankEqual

O

Y or N

It identifies if a rank has been equalled.

In PiT message only Y value has sense.

N

Only if necessary

ResultType

O

CC @ResultType

Type of the @Result attribute

N

Only if necessary

Result

O

MM:SS.hh

99:90.00

The cumulative result of the competitor

N

Only if necessary

IRM

O

CC @IRM

The invalid rank mark, in case it is assigned

N

Only if necessary

QualificationMark

O

CC @QualificationMark

The code which gives an indication on the qualification of the competitor for the last heat of the competition (when there are 4 heats it should be informed in heat 3)

N

T3

SortOrder

M

Numeric

Used to sort all cumulative results, based on rank, but to break rank ties, etc. It is mainly used for display purposes.

N

Only if necessary

 

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

CC @Phase

Phase code of the latest RSC schedule item (either phase or unit) to which the cumulative results is updated to.

N

T3

Unit

O

CC @Unit

Unit code of the latest RSC schedule item to which the cumulative results is updated to. It should be informed just in the case the latest schedule item is an event unit. Otherwise, do not include.

N

T3

 

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

Text

Rank of the competitor in the result for the event unit or phase identified by /ResultItems /ResultItem.

N

T3

RankEqual

O

Y or N

It identifies if a rank has been equalled.

In PiT message only Y value has sense.

N

T3

ResultType

O

CC @ResultType

Type of the @Result attribute for the event unit or phase identified by /ResultItems /ResultItem

N

T3

Result

O

MM:SS.hh

99:90.00

The result of the competitor in the event unit for the event unit or phase identified by /ResultItems /ResultItem

N

T3

IRM

O

CC @IRM

The invalid rank mark, in case it is assigned for the event unit or phase identified by /ResultItems /ResultItem

N

T3

QualificationMark

O

CC @QualificationMark

The code which gives an indication on the qualification of the competitor for the last heat of the competition, informed in the immediately previous event unit (when there are 4 heats it should be informed in heat 3) identified by /ResultsItems /ResultItem

N

T3

SortOrder

M

Numeric

Used to sort all results in an event unit or phase identified by /ResultItems /ResultItem

N

T3

 

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

Or Organisation code in the case of NOC or NPC

Competitor’s ID

N

T3

Type

M

T,A, N

T for team

A for athlete

N for NOC or NPC

N

T3

 

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

T3

Order

M

Numeric

Order attribute used to sort team members in a team (if Competitor @Type=”T”) or 1 if Competitor @Type=”A”.

N

T3

Bib

M

N(3)990

Bib number

N

T3

 

Result /Competitor /Composition /Athlete /ExtendedResults /ExtendedResult

 Team member’s or individual athlete’s extended result, depending on whether Competitor @Type=”T” or Competitor @Type=”A”.

Type

Code

Pos

Value

Description

ER_SN

SN_DIFF

 

+MM:SS.hh

+99:90.00

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Pos:

Do not send anything

- For @Value:

Cumulative time difference after the finalisation of the current event unit (for Result @Rank=1, send 0.00)

 

MM is minutes, SS is seconds, hh is hundredth of second

SN_LAST_QUALIFIED

 

S(1) Y or N

- For @Type: Send proposed type

- For @Code: Send proposed type

- For @Pos: Do not send anything.

- For @Value: Send Y when competitor is the last competitor qualified according to sport rules. (See table below for more information)

 

For the table above, we have the following additional/summary information:

 

Type/Code

Description

Expected

RT Only

RT Trigger

ER_SN/ SN_DIFF

Cumulative time difference after event unit

Always

N

T3

ER_SN/ SN_LAST_QUALIFIED

The competitor is the last one to qualify according to rules. It is the virtual last qualified position in the current moment.

Always

N

T3

 

 

 

 

3.2.4.6  Message Sort

The message sorting order is the same as that explained in the Event Unit / Phase Results messages.


 

 

3.2.5    Event Final Ranking

3.2.5.1  Description

The event final ranking is a message containing the final results and ranking at the completion of one particular event, either competing as single athletes or as aggregated athletes.

 

The final ranking message is a generic message for all sports, including the full event final result for all competitors that were either ranked, got an Invalid Rank Mark (disqualified, etc.), or both.

 

Depending on the sport rules it may include all competitors in the competition as all can be ranked (as in Marathon) or may only include this with a final ranking as other are unranked (as in tennis).

 

 

3.2.5.2  Header Values

3.2.5.2.1  PiT Header

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_RANKING

Event Final ranking message

ResultStatus

CC @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

CC @VenueCode

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.

 

 

3.2.5.3  Trigger and Frequency

3.2.5.3.1  PiT Triggers

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.

 

 


3.2.5.4  Message Structure

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

 

 

 

 

 

ExtendedResults (0,1)

 

 

 

 

 

 

ExtendedResult (1,N)

 

 

 

 

 

 

Type

 

 

 

 

 

Code

 

 

 

 

 

Pos

 

 

 

 

 

Value

 

 

 

Composition

 

 

 

 

 

 

Athlete (1,N)

 

 

 

 

 

 

Code

 

 

 

 

 

Order

 


3.2.5.5  Message Values

Competition

Attribute

M/O

Value

Comments

Code

M

CC @Competition

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

Text

Final rank of the competitor in the corresponding event. This attribute is optional because the competitor may have got an invalid rank mark.

RankEqual

O

Y

It identifies if a rank has been equalled.

ResultType

O

CC @ResultType

Result type, either time or IRM for the corresponding event.

Result

O

MM:SS.hh

99:90.00

Final result for the particular event.

 

Send just in the case @ResultType is Time (see codes section)

 

MM is minutes, SS is seconds, hh is hundredth of second

IRM

O

CC @IRM

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.

 

Result /Competitor

Competitor related to one final event result.

Attribute

M/O

Value

Comments

Code

M

S(20) with no leading zeroes

,NOC ID or TBD

Competitor’s ID.

If NOC or NPC, the value will be NOC ID.

If the competitor is not known or does not exist, the value will be TBD.

Type

M

T,A, N

T for team

A for athlete

N for NOC’s or NPC’s

 

Result /Competitor /ExtendedResults /ExtendedResult

Team competitor’s  extended results, according to competitors’ rules.

Type

Code

Pos

Value

Description

ER_SN

SN_DIFF

 

+MM:SS.hh

+99:90.00

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Pos:

Do not send anything

- For @Value:

Time difference for the event’s final result (for Result @Rank=1, send 0.00)

 

MM=minutes

SS=seconds

hh=hundredth of second

 

For the table above, we have the following additional/summary information:

 

Type/Code

Description

Expected

ER_SN/ SN_DIFF

Event’s time difference

Always

 

 

 

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”.

 

 

3.2.5.6  Message Sort

Sort by Result @SortOrder


 

 

3.2.6    Event’s Medallists

3.2.6.1  Description

The “Event’s Medallists” is a message containing the list of medallists awarded in one particular event.

 

 

3.2.6.2  Header Values

3.2.6.2.1  PiT Header

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

CC @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

CC @VenueCode

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

 

 

3.2.6.3  Trigger and Frequency

3.2.6.3.1  PiT Triggers

The message should be sent with ResultStatus=PARTIAL when the information of the medallist is know but the final event Unit is not finished.

 

The message should be sent with ResultStatus=OFFICIAL when the medallists are official known when the final event unit finishes.

 

Trigger also after any major change.

 

 


3.2.6.4  Message Structure

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

 


3.2.6.5  Message Values

Competition

Attribute

M/O

Value

Comments

Code

M

CC @Competition

Unique ID for competition

 

Medal

Attribute

M/O

Value

Comments

Code

M

CC @MedalType

Medal type.

 

All the Competitors with the same CC@MedalType are not grouped in the same element.

Phase

M

CC @Phase

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

CC @Unit

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”.

 

 

3.2.6.6  Message Sort

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.


 

 

3.2.7    Discipline Configuration

3.2.7.1  Description

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=“”).

 

 

3.2.7.2  Header Values

3.2.7.2.1  PiT Header

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

CC @VenueCode

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

 

 

3.2.7.3  Trigger and Frequency

3.2.7.3.1  PiT Triggers

When this information is available.

 

 


3.2.7.4  Message Structure

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

 


3.2.7.5  Message Values

Competition

Attribute

M/O

Value

Comments

Code

M

CC @Competition

Unique ID for competition

 

Configs /Config

Attribute

M/O

Value

Comments

Gender

O

CC @DisciplineGender

Gender code of the RSC. Include if information is by Gender, by Event, by Phase or by Event Unit. Otherwise, do not include.

Event

O

CC @Event

Event code of the RSC. Include if information is by Event, by Phase or by Event Unit. Otherwise, do not include.

Phase

O

Numeric

Phase code of the RSC. Include if information is by Phase or by Event Unit. Otherwise, do not include.

Unit

O

Numeric

Unit code of the RSC. Include if information is by Event Unit. Otherwise, do not include.

 

Configs /Config /ExtendedConfig

Type

Code

Pos

Value

Description

EC_QUALIFICATION_RULE

SN_RANK_QUALIFY_NEXT_ROUND

Numeric

Numeric

- For @Type:

Send proposed type

- For @Code:

Send the proposed code for the qualification rule.

QR_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

EC_SN

SN_ALTITUDE_START

 

Numeric

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Value:

Start altitude in meters

SN_ALTITUDE_FINISH

 

N(4)

9999

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Value:

Finish altitude in meters

SN_ALTITUDE_DROP

 

N(4)

9999

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Value:

Vertical drop in meters

SN_LENGTH

 

N(4)

9999

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Value:

Length of course in meters

SN_INTERMEDIATE_RESULT_DIST

Numeric

N(4).N(1)

9999.9

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Pos:

The number that identifies the

intermediate result point, from 1 to

the total number of intermediate

result points

- For @Value:

Distance in meters with one decimal digit of the intermediate

result point (e.g.: 2000.6)

SN_TOP_SPEED_POINT

 

N(2)

- For @Type:

Send proposed type

- For @Code:

Send proposed code

- For @Value:

The number that identifies the intermediate point where is reached the top speed in the track.

 

For the table above, we have the following additional/summary information:

 

Type/Code

Description

Expected

EC_QUALIFICATION_RULE/ SN_RANK_QUALIFY_NEXT_ROUND

Qualification Rule

Always if the rule applies to the competition

EC_SN/ SN_ALTITUDE_START

Start altitude in meters

Always

EC_SN/ SN_ALTITUDE_FINISH

Finish altitude in meters

Always

EC_SN/ SN_ALTITUDE_DROP

Vertical drop in meters

Always

EC_SN/ SN_LENGTH

Length of course in meters

Always

EC_SN/ SN_INTERMEDIATE_RESULT_DIST

Distance for the

intermediate result point in meters

Always

EC_SN/ SN_TOP_SPEED_POINT

Intermediate point where is reached the top speed in the track.

Always

 

 

 

 

3.2.7.6  Message Sort

There is no general message sorting rule.


 

 

3.2.8    Event Unit Weather Conditions

3.2.8.1  Description

The “Event Unit Weather Conditions” is a message containing the weather conditions in the Event Unit.

 

 

3.2.8.2  Header Values

3.2.8.2.1  PiT Header

The following table describes the ODF header attributes

 

Attribute

Value

Comment

DocumentCode

DD0000000

DD according to CC @Discipline

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

CC @VenueCode

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

 

 

3.2.8.3  Trigger and Frequency

3.2.8.3.1  PiT Triggers

This messages should be sent each hour during session.

 

 


3.2.8.4  Message Structure

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

 

 

 

 

Prec_Type

 

 

 

 

Condition (0,3)

 

 

 

 

 

Code

 

 

 

 

Value

 

 

 

Temperature (0,N)

 

 

 

 

 

Code

 

 

 

 

Unit

 

 

 

 

Value

 

 

 

 

Type

 

 

 

Wind (0,N)

 

 

 

 

 

Code

 

 

 

 

Unit

 

 

 

 

Value

 


3.2.8.5  Message Values

Competition

Attribute

M/O

Value

Comments

Code

M

CC @Competition

Unique ID for competition

 

Weather /Conditions

Attribute

M/O

Value

Comments

Code

M

START, FINISH

Weather Points

Humidity

O

N(3)

Humidity in %

Wind_Direction

O

CC @WindDirection

Wind direction

Prec_Type

O

CC @PrecType

Precipitation type

 

Weather /Conditions /Condition

Send two times in the case of Winter conditions.

Attribute

M/O

Value

Comments

Code

M

SKY or ICE

Weather conditions type

Value

M

CC @SnowConditions

Or

CC @WeatherConditions

Codes that describe the Sky or Ice  Condition.

Use CC @WeatherConditions for SKY Conditions

Use CC @SnowConditions for ICE Conditions

 

Weather /Conditions /Temperature

Send with two different @Code in the case of Winter conditions.

Attribute

M/O

Value

Comments

Code

M

AIR, ICE

Mandatory in Winter (if the information is available for the Event Unit)

Unit

M

F,C

Metric system unit for temperature

Value

M

-N(3).N(1) -990.0 or N(3).N(1) 990.0

Temperature in centigrade degrees (in case of positive temperature, do not send '+')

Type

O

Text

Type of Temperature (like Maximum, Minimum, Normal, etc.)

 

Weather /Conditions /Wind

Attribute

M/O

Value

Comments

Code

M

SPEED

Wind  Speed

Unit

M

MS , KMH

Metric system unit for Wind

Value

M

N(3).N(1)

990.0

Wind Speed

 

 

3.2.8.6  Message Sort

There is no special sort order requirement for this message. Usually, Conditions@code is the attribute used to sort the conditions.


 

 


 

4   Messages Sequence

1. All Events Training

Message

DocumentCode

DocumentSubType

ResultStatus

Comments

DT_START_LIST

DDGEEEPUU

N/A

N/A

Start List for Training n

DT_RESULT

DDGEEEPUU

N/A

LIVE_UPDAT

Real Time Results for Training n

DT_RESULT

DDGEEEPUU

N/A

UNOFFICIAL

Unofficial Results for Training n

DT_RESULT

DDGEEEPUU

N/A

LIVE_LAST

End of Real Time Results for Training n

DT_RESULT

DDGEEEPUU

N/A

OFFICIAL

Official Results for Training n

 

2. All Events Competition

Message

DocumentCode

DocumentSubType

ResultStatus

Comments

DT_START_LIST

DDGEEEPUU

N/A

N/A

Start List for Heat n

DT_RESULT

DDGEEEPUU

N/A

LIVE_UPDAT

Real Time Results for Heat n

DT_CUMULATIVE_RESULT

DDGEEE000

DDGEEEPUU

LIVE_UPDAT

Real Time Cumulative Results for Heat n

DT_RESULT

DDGEEEPUU

N/A

UNOFFICIAL

Unofficial Results for Heat n

DT_CUMULATIVE_RESULT

DDGEEE000

DDGEEEPUU

UNOFFICIAL

Unofficial Cumulative Results for Heat n

DT_RESULT

DDGEEEPUU

N/A

LIVE_LAST

End of Real Time Results for Heat n

DT_CUMULATIVE_RESULT

DDGEEE000

DDGEEEPUU

LIVE_LAST

End of Real Time Results for Heat n

DT_RESULT

DDGEEEPUU

N/A

OFFICIAL

Official Results for Heat  n

DT_CUMULATIVE_RESULT

DDGEEE000

DDGEEEPUU

OFFICIAL

Official Cumulative Results for Heat n

DT_RANKING

DDGEEE000

N/A

OFFICIAL

Event Final Ranking

 

 

 

5   Codes

5.1  Global Codes

Code Entity

Format

Entity Description

Link

CC @AccreditationStatus

S(6)

Defined in ODF Common Codes Document

 

See entity Accreditation Status

• The entity’s attribute to be used is Id

Link

CC @Competition

S(7)

Defined in ODF Common Codes Document

 

See entity Competition

• The entity’s attribute to be used is Id

Link

CC @Country

S(3)

Defined in ODF Common Codes Document

 

See entity Country

• The entity’s attribute to be used is Id

Link

CC @Discipline

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’

Link

CC @DisciplineGender

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

Link

CC @Event

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

Link

CC @Function

S(30)

Defined in ODF Common Codes Document

 

See entity Function

• The entity’s attribute to be used is Id

Link

CC @MedalType

S(9)

ME_BRONZE : Bronze

ME_GOLD : Gold

ME_SILVER : Silver

 

CC @Organisation

S(3)

Defined in ODF Common Codes Document

 

See entity Organization

• The entity’s attribute to be used is Id

Link

CC @PersonGender

S(1)

Defined in ODF Common Codes Document

 

See entity Person Gender

• The entity’s attribute to be used is Id

Link

CC @Phase

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

Link

CC @PrecType

S(1)

R : Rain

S : Snow

 

CC @RecordCode

S(12)

Defined in ODF Common Codes Document

 

See entity Record

• The entity’s attribute to be used is Id

Link

CC @RecordType

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

Link

CC @ResultStatus

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.

 

CC @SportClass

S(8)

Defined in ODF Common Codes Document

 

See entity Sport Class

• The entity’s attribute to be used is Id

 

CC @Unit

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

Link

CC @VenueCode

S(3)

Defined in ODF Common Codes Document

 

See entity Venue

• The entity’s attribute to be used is Id

Link

CC @WeatherConditions

S(6)

Defined in ODF Common Codes Document

 

See entity Weather Condition

• The entity’s attribute to be used is Id

Link

CC @WindDirection

S(3)

Defined in ODF Common Codes Document

 

See entity Wind Direction

• The entity’s attribute to be used is Id

Link

 

 

5.2  Skeleton Codes

Code Entity

Format

Entity Description

CC @IRM

S(5)

DNF : Did not finish

DNS : Did not start

DSQ : Disqualified

(The codes order provided is according to the sport rules. If more than one crew have the same IRM, they should be sorted based on number of completed heats/segments. Competitors having the same IRM and the same number of completed heats /segments should be sorted by bib number).

CC @QualificationMark

S(7)

Q: Qualified (to participate in the last heat)

CC @ResultType

S(13)

IRM : Invalid Result Mark

TIME : Time

 


 

6   General definitions

 

6.1    ODF Message Structure

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>

 

 

6.1.1  ODF Declaration

The first line in an ODF message is the XML declaration. It defines the XML version and the encoding used, UTF-8.

6.1.2  ODF Header

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.

 

 

6.1.3  ODF Body

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

<Competition> Element

An ODF message contains a mandatory element <Competition>.

Element

Attribute

M/O

Value

Comment

Competition

Code

M

CC @Competition

 

Unique ID for the competition

 

 

<Message> Element

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.

<Competitor> 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.

6.2    ODF Data Types and Formats

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