SaneSeis is my proposed alternative file format for acquiring Shot Domain seismic data. It avoids the complications of SEGD, SEGY and SEG2.
At this stage it is a proposed format. It will likely need some tweaking before it can be fully implemented in a production environment - if it ever is.
I welcome constructive feedback.
At this stage it is a proposed format. It will likely need some tweaking before it can be fully implemented in a production environment - if it ever is.
I welcome constructive feedback.
The SEG file formats currently used for seismic acquisition (SEGD, SEGY SEG2) are based on decades old concepts that do not apply to modern seismic operations.
Presented here is a format proposal for shot domain data sets that attempts to resolve the issues with the SEG file formats. It attempts to eliminate all ambiguities. The object is to be able to quickly and easily write and read seismic data files. Informational parts of the header are text that can be read by anyone with a text editor. It is an acquisition level format only - not a processing format. A processing format may be defined later depending on reception of this format description.
Presented here is a format proposal for shot domain data sets that attempts to resolve the issues with the SEG file formats. It attempts to eliminate all ambiguities. The object is to be able to quickly and easily write and read seismic data files. Informational parts of the header are text that can be read by anyone with a text editor. It is an acquisition level format only - not a processing format. A processing format may be defined later depending on reception of this format description.
- Little endian encoding (Intel) will be used
- Floating point values and trace data values will be encoded as 32 bit floating point values as per IEEE754
- Text entries are ASCII
- All headers are mandatory and all entries must be filled.
- File length will be limited to a maximum of 60 Seconds regardless of sample rate.
- All channels in the file use the same sample rate and number of samples
- The first sample is T0 (IE for a record length of 1000mS at 1mS SR, there are 1001 discrete samples, this is the way Sercel currently work)
- Coordinates are UTM and coordinate values in metres
- A source table contains source and start time information
- Up to 255 sources are permitted in a file (ID 1 - 255)
- A virtually unlimited number of source starts may appear in any file
- A source may start more than once within a file - each start requires an entry in the source table
- Continuous recording is supported.
- A manufacturer and user header are included
- The file format uses 'Flat' headers - except for the source table which may be variable length. This means that parts of headers do not need to be decoded to interpret later parts which in turn must be decoded to arrive at the number ofchannels in a file as is the case with SEGD. There are no channel sets as in SEGD.
- The source table may include null entries - IE unused start entries. This allows for a fixed table size to be defined for projects if desired. E.g. if 22 vibrators are assigned to a crew, but only 16 used at any one time in continuous production,the source table may be fixed at 22 sources if desired.
- The receiver table includes array sensitivity, meaning true amplitude can be recovered
- The manufacturer header can contain any manufacturer data (text and/or binary data), but for the file to conform to the format, the manufacturer must publish a full description of all entries in the header.
- The user header is intended for such things as weather station information or other miscellaneous data that is project specific. It is text only and free form.
- Trace headers are flat and contain all positioning, trace assignment and QC information
Updated 18-October-2015 - changes shown in Red
The source table repeats for as many source starts as are defined in the file header
The Receiver table repeats for as many receivers as are defined in the file header
