$Id: requirements.txt,v 1.7 2008/05/27 16:11:31 rhb Exp $

           Draft SEG-Z Motivation and Requirements

SEG-Z Is Needed Because:

   Neither revision 0 nor revision 1 of the SEG-Y standard accurately
   reflects widespread industry practice. Both LittleEndian
   datasets and floating point header fields are widely supported
   despite not being allowed in either revision. The presence of
   unallocated space in the headers has led to conflicts among
   revision 0 implementations. In addition, the failure of revision
   0 to reserve space in the headers for future use has led to
   conflicts between revision 0 implementations and revision 1 of
   the standard.

   The fixed size of the header and disjoint models for processing
   system metadata make transfer of datasets using SEG-Y inherently
   lossy. The transfer of a dataset from software package A to B
   and then back to A will generally require reconstructing many
   headers that A uses for which no analog exists in B. Such
   transfers are often required if specialty processing of a
   dataset with proprietary algorithms is desired.

   QC procedures for verifying metadata become increasingly
   intractable as dataset sizes increase if metadata is interleaved
   with the corresponding data. Both hardware firmware and
   operating system software will detect sequential access pattern
   and force a read of the entire dataset when only a small portion
   is actually needed. Only by separating the metadata from the
   data can this important process be speeded up.

   For multicomponent data and 4D data, the duplication of header 
   information inherent in the SEG-Y model is inefficient and 
   susceptible to inconsistencies.

   There is no protection against medium errors and dataset
   corruption except what is provided by the hardware firmware.
   Thus, corruption caused by software errors is undetectable and
   most medium errors result in recopying the entire dataset. As
   datasets grow to exceed a terabyte this becomes increasingly
   unsatisfactory.

   The original SEG-Y on tape used the interleaving of header and 
   data in a trace to provide minimal data loss semantics.  However,
   this advantage is lost in SEG-Y on disk implementations.

   Prescriptive formats such as SEG-Y inevitably become less useful
   as technical requirements evolve. Only a descriptive standard
   which mandates how a dataset is described rather than what it
   contains can overcome this problem.


SEG-Z Format Must Support:

   The ability to make any SEG-Y variant dataset consisting of a
   single line level metadata block with a single metadata block per
   trace data block SEG-Z compatible by the addition of a SEG-Z
   descriptor.

   The ability to describe any seismic survey dataset written with a
   static format consistent with the following limitations:

      A single instance of an arbitrary length text header

      A single instance of an arbitrary binary line header structure

      One or more instances of a single arbitrary fixed size trace
      header structure

      One or more instances of a single arbitrary fixed size trace
      data structure w/ both vector of structure and structure of
      vectors (e.g. vector of complex or separate real & imaginary
      vectors) In the case of a structure of vectors, different
      lengths for each vector must be permitted.

   The ability to present the trace headers and data either in
   interleaved form as a trace composed of header and data segments
   or as separate blocks of headers and data


With The Following Constraints:

   Exactly one trace header segment per trace data segment

   Dynamic (i.e. user defined) headers w/ reserved names for all
   SEG-Y revision 0 & 1 headers (e.g SEGY_<?????>)

   An unambiguous human and machine readable format description w/ 
   detection  and reporting of all format description errors via
   intelligible messages

   Independence of transfer medium whether tape, disk, network
   connection or other medium

   Ability to detect and recover from data transfer errors
   independently of firmware or medium error detection facilities
   with minimal data loss