| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
WFDB applications may generally assume (and most of them do assume) that all
annotations in any given annotation file are in canonical order.
Successful use of iannsettime requires that this assumption be correct.
The earliest versions of the WFDB library (before version 6.1) defined
canonical order as time order. Versions 6.1 through 10.4.11 define canonical
order as time and chan order, and versions 10.4.12 and later also
use num for ordering (thus annotations are arranged first in time
order, and any simultaneous annotations are arranged according to the value of
their num fields, from smallest to largest, and those with identical
num fields are similarly arranged in chan order).
The combination of the time, num, and chan fields of an
annotation defines a unique location in a virtual array of
annotations which an annotation file represents. No two annotations may
occupy the same location in this virtual array. This restriction was
enforced by versions of the WFDB library earlier than version 9.7. In
these versions of the WFDB library, putann required that
annotations be written in canonical order, and refused to write any
out-of-order annotations supplied to it.
Current versions of the WFDB library do not impose this requirement. In version
9.7 and later versions, putann accepts and records out-of-order
annotations and multiple annotations that occupy the same location. If any
such annotations have been written, the completed annotation file is rewritten
in canonical order by wfdbquit or oannclose. This is accomplished
by running ‘sortann’ (see the WFDB Applications
Guide) as a separate process using the ANSI C system function. If this
function is not available, or if ‘sortann’ cannot be run, wfdbquit
(or oannclose) emits a warning message describing how to post-process
the annotations to put them into canonical order.
Although it is possible using current versions of the WFDB library to write two
or more annotations to the same location, only the last annotation
written to any given location is retained in the canonically-ordered
annotation file. Thus that an application that generates an annotation file
can change the anntyp, subtyp, or aux fields of a
previously-written annotation simply by writing another annotation to the same
location (i.e, with the same time, num, and chan fields).
As a special case, an application may delete a previously-written
annotation by writing a NOTQRS annotation to the same location. To move
an annotation to a different location (i.e., to change its time,
num, or chan fields), it is necessary to delete it from the
original location, and then to insert it at the desired location, using two
separate invocations of putann.
In unusual circumstances, an unsorted annotation file may be useful (for
example, as an aid for debugging the application that produced it; ‘rdann’
can be used to list all of the annotations in such a file, in the order in
which they were written). In some environments, the use of the ANSI C
system function may be a security problem, and you may wish to avoid
automatic sorting of annotations for this reason. Set the environment variable
WFDBANNSORT to 0 at run time, or define the symbol DEFWFDBANNSORT
as 0 when compiling the WFDB library, if you wish to suppress automatic
annotation sorting by wfdbquit and oannclose.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] |
PhysioNet (wfdb@physionet.org)