Proposed SEGP-2010 Standard

March 2, 2010

---

Geophysicists have been asking for enhancements to SEGP:

1. UKooa was designed for the marine situation and tweleve characters for a line name just isn't enough!
2. A standard way to read any SEGP like format containing a free format Descriptive Textual Header, an optional fixed File header followed by point positional data. I need to identify data stored in decimeters vs meters. I need more columns to define my Line Name. I need more precision! How do I handle my implied decimal points? Can I improve the readability of the format? How do I add new observations? I need time finer than seconds.
3. The new format needs to be machine readable.
4. How about a Variable Length, Dynamic Header specification? The format needs to have the ability to grow over time. I only want to define what I am using; I want to leave fields undefined.
5. In addition to ASCII number types, the new format should permit integers, floating point numbers and double precision (64bit) numbers as big or little endian.
6. There is too much wiggle room with the existing formats. We need a built in mapping or keyword file called the DESCRIPTOR to enable automatic data loading to the workstation or conversion of the data.

The recommended SEGP format can be thought of as a 1983 SEGP or 1990 UKooa object containing a preamble that describes the format of the data and headers. This then becomes a self defining format!:

• Add a mapping file (DESCRIPTOR) to the front of every segp that can describe any adaptation for positional data. Or perhaps have the descriptor as a separate file, perhaps with a suffix of .map
• Provide a new format that can easily be extended to handle the needs of the future, i.e. variable header lengths, dynamic field definitions.

The DESCRIPTOR contains an ascii description of the organization of the data that can easily be parsed.

An idea for the SEGP-2010 format contains:

1. A Textual File Header
2. A Binary (fixed position) File Header (optional?)
3. and point positional data

Here is what a typical DESCRIPTOR might look like tacked onto some previously generated SEGP data!:

SEGP_Format_Definition_2010

# This format definition is used to define the SEGP files that are created by Kelman's iGlass software.
# Dated February 4, 2010

SECTION FileStructureDefinition

# SECTION is the keyword identifier for the beginning of a section
# Comment - This header defines a normal SEGP file
  Name,             Length, Description
  TextualHeader,      1640, # 20 lines of 80 characters plus a CRLF (2 bytes each line)
  FileHeader,            0, # Length of file fixed header (bytes) for data such as Datum, Projection, Central Meridian (not used in this case)
  PointData,            82, # Length of trace header (bytes)
  Endian,           LITTLE, # Big Endian data suitable for SUN type computers, not required for ASCII data
 ENDSECTION

 SECTION PointDataDefinition

  Name,       Byte,Type, Count, Scalar
  BLANK,         1,ASCII,    1           # Space means point data, otherwise header data 
  LINE_NAME,     2,ASCII,   16           # Line Name
  SOURCE_POINT, 18,ASCII,    8           # Energy source point number (shot peg)

  LAT_DEG,      27,ASCII,    2           # Latitude Degree
  LAT_MIN,      29,ASCII,    2           # Latitude Minutes
  LAT_SEC       31,ASCII,    4           # Latitude Decimal Seconds
  LAT_NS,       35,ASCII,    1           # Latitude North or South of the equator

  LONG_DEG,     36,ASCII,    3           # Longitude Degree
  LONG_MIN,     39,ASCII,    2           # Longitude Minutes
  LONG_SEC,     41,ASCII,    4           # Longitude Decimal Seconds
  LONG_EW,      45,ASCII,    1           # Longitude East or West of Central Meridian
  CDP_X,        46,ASCII,    8           # Local coordinate (X) of ensemble (CDP) for this trace Latitude Degree
  CDP_Y,        54,ASCII,    8           # Local coordinate (Y) of ensemble (CDP) for this trace Longitude Degree
  ELEV,         62,ASCII,    5,   .1     # Elevation or water depth at source point. (data stored in deci meters)
  CRLF          81,ASCII,    2           # Carriage return Line Feed for Windows type ASCII files
 ENDSECTION
ENDSEGP
# More reporting stuff can go here...
# Here is what an example of a Kelman SEGP file generated for EnCana:
# Note the ENDFILE keyword identifier for the end of the (format) file.
H  Standard Format                                                              
H CLIENT   :                                                                    
H LINE NAME: GUESS                       KTI LINE ID: 1311134515                
H LINE ID: A98123                                                               
H PROSPECT : WAPITI                      PROJECT ID: A6278                      
H CONTRACTOR: VERITAS GEOSERVICES LTD                                           
H SURVEY CO.: VERITAS GEOSERVICES LTD                                           
H SURVEY DATE:                           SURVEY METHOD: AUDIT ASSMT             
H PRODUCED BY: KELMAN TECHNOLOGIES INC.  DATA OWNERSHIP: PURCHASED              
H FIRST SP: 104           LAST SP: 1518            SP INT.:                     
H PROJECTION : UTM                                                              
H CENTRAL MERIDIAN: -117  ZONE CODE : 11           DATUM : NAD27                
H SURVEY GRID: 164                       SURVEY H CONF:                         
H SURVEY V CONF:                         LINE LENGTH: 11.06                     
H SHOT FOR: ESSO RESOURCES (CANADA) LTD.                                        
H SHOT BY: WESTERN GEOPHYSICAL (CANADA)                                         
H COMPLETE DATE: 1961-01-01 00:00:00.0   ENERGY SOURCE: VIBROSEIS               
H                                                                               
H<.....LINE.....><..SP..> <..LAT..><..LONG..><.EAST.><.NORT.>              
H........1.........2.........3.........4.........5.........6.........7.........8
 A98123              1049 55 61828N119315963W 338389061092004 7035              
 A98123              1050 55 61828N119315794W 338419061091993 7036              
 A98123              1051 55 61828N119315625W 338448961091981 7037              
 A98123              1052 55 61828N119315456W 338478961091970 7039              
 A98123              1053 55 61827N119315287W 338508961091958 7040              
 A98123              1054 55 61827N119315117W 338538961091947 7041              
 A98123              1055 55 61827N119314948W 338568861091935 7041              
 A98123              1056 55 61827N119314779W 338598861091924 7044              
 A98123              1057 55 61826N119314610W 338628861091912 7046
 ....
ENDFILE
# If endfile isn't there, you are missing data!
             

Introduction

This web site describes a CSEG (Calgary) new seismic positional data exchange format based on the ideas collected over several years. The main ideas came from the customers of SEGP data, the interpretation workstations (SeisWare International). This is a real switch, letting the customer get involved in the format of the data instead of being controlled by the supplier!

Design Aims

Our aims in designing SEGP have been to provide the industry with a seismic data exchange format that is:

• Flexible enough that is should serve us well for the next few decades. Backwards comptable to UKooa and SEGP.
• Easy enough to use and implement so that it is quickly adopted as a working standard throughout the industry
• Able to save field definitions in a wide range of data types
• As the majority of seismic data is currently archived in the myriad versions of SEGP and UKooa, we think it desirable to be able to read in those files using SEGP-2010 reading software, with minimal user input.

In short, we wish to remove the Tower of Babel erected by SEGP and UKooa, and let Geophysicists get on with their real job of seismic processing or interpretation. We need more characters to describe our line names!

SEGP Descriptor Rules

• Fields are comma-delimited, case insensitive. White Space is legal.
• The letters SEGP_Format_Definition_2010 are the first line of the descriptor. In addition to signature bytes, the version number is also contained on this line.
• The first line of each preamble stanza should be a list of TAGS. Tags currently include: Name, Length, Byte, Type, Count, Scalar, Addend and Description. Some tags can be optional (Scalar and Addend) and some may only apply to certain stanzas (eg Length applies to the SEG-Z parameters stanza). Reading software must recognizz the tags that are described by the format. SEGP files can contain new tags, but the reading software must bypass any fields for tags that it doesn't recognise. The SEGP standard will be deemed to be broken if REQUIRED TAGS (eg Name, Byte..) are missing from the file.
• Normally, Defaults are not allowed.
• Default for SCALAR is 1.0, and ADDEND is absent is 0.0. COUNT is assumed to be 1. Scaler is a multiplier, a scalar of 10 means you multiply the number in the field by the number 10. A scaler of 0.25 means you multiply (same as divide by 4). The order of operations is to multiply first and then apply the addend. (applied after the scalar)
• Comments start with the character #
• Values stored in the header over ride the data. Values stored in a separate format file over ride both the preamble header and the Line header.

Identifying Header

The Identification header at the start of the file is SEGP-Format-Definition-V1(coded in ASCII). The same byte ordering must be used throughout the file. The complete list of Valid Names, descriptions and probable SEGY byte positions are stored here.

Here is a list of proposed number and character formats.

Data Type	Description
INT1	1-byte integer
INT2	2-byte integer
INT4	4-byte integer
INT8	8-byte integer
UINT1	1-byte unsigned integer
UINT2	2-byte unsigned integer
UINT4	4-byte unsigned integer
UINT8	8-byte unsigned integer
IEEE4	4-byte IEEE float
IEEE8	8-byte IEEE float
IBM4	4-byte IBM float
ASCII	American Standard Code for Information Exchange

The Data types are straight forward and can even handle 64 bit numbers!

Assorted Reference Material

PS: This format can be used to extract the positional data stored as SEGY, all we need to add is the number format code and the number of samples in order to extract navigation out of a SEGY file!

Assorted Documents

1. SEGP1,2,3 1983 documentation with example from Kelman Archives, 2010
2. UKooa P190 original 1990 Documentation with Data Example

Feel free to contact the author, Eric Keyser (403) 645-3589 or send me an email. Are my ideas crazy or is this a good way to map out navigation for the future. How can we make this better? Your comments are welcome.

---

Site Owner: Eric Keyser