Clay Harter Chief Technology Officier OpenSpirit Corporation www.openspirit.com +1 281 -295-1407 August 5, 2005 Clay fully agrees "that the SEGY standard needs some enhancement in order to support the more efficient exchange of data and also to serve as a workstation format" They are advocating -xml file to describe survey, project and to provide a trace index to allow rapid direct access to random traces -Double precision spatial coordinates -Survey coordinate system (suggest using EPSG standards) Jonathan Reid SLB 294-4371 August 4, 2005 They do not see any problems handling the format, they will pass this on to the developers team. Dave Morgan, Geo-X January 20, 2003 Started coding Geo-X version of the Encana standard: Binary Header, Reduce the space for the reference number from 12 to 8 bytes to leave room for their internal check program. Eight bytes should be enough for our needs. Will revisit when needed. Leave byte 399 as zero unless the segy version is 100% SeisX comptable. Put the number 1 in 400 as the Encana flag. Change trace header Trace sequential counter within line to I4 to handle large number of traces in 3D's. There was room for this anyways. Dave Morgan ######################################################## Mr. Keyser, Thank you for your comments. The SEG Technical Standards Committee establishes consensus standards based on feedback and comment from the seismic industry. As you point out on your web page there are a number of features within SEGY rev 1 that could be implemented in a different manner. One example is the use of scaled integer values instead of floating point numbers. Many such points were considered by the subcommittee while SEGY was being revised. The industry consensus was to retain many of the existing structures within SEGY rev 0 and to maintain backward compatibility with the SEGY rev 0 format. The SEGY formats are intended as data exchange formats. As such they by definition will not contain all of the proprietary data associated with an acquisition or processing shop. To accommodate this SEGY rev 1 provides stanza structures which allow proprietary data to be included within the SEGY data stream. I would suggest that this is the proper mechanism for your group to use to include additional data items and identification information. Best regards Alan Faichney Chairman, SEG Technical Standards Committee Sent: Tuesday, October 29, 2002 10:17 AM To: 'Alan Faichney' Cc: Michael W. Norris (E-mail) Subject: Encana SEGY standard Thanks for your comments concerning our initiative. We are proceeding with our Encana SEGY standard. Definition of a Standard: Regularly and widely used, available, supplied, well-established and very familiar having recognized and permanent value, substantially uniform and well established by usage. The standard that resulted from SEGY rev 0 was 3200 byte descriptive, 400 byte line header and 128byte trace header followed by variable length data. The data populated in these fields vary by company and are far from consistent or standard. A standard becomes a standard only when it becomes accepted and is regularly and widely used. More than 12 years ago, Photon created the SeisX standard that used floating point numbers in the headers. It is estimated that more than a million seismic lines exist in SeisX SEGY. We deem it important to maintain backward compatibility with this standard. Eliminating the data loading step is an important feature for our user community. In order to gain acceptance with the various vendors, it is important for the standard to be simple and easily understood. I have looked at the new stanza definition and find that it is too complicated to be included at this point in time. In order to quickly gain acceptance we are proposing to define signature bytes to enable automatic detection and to place into the public domain a check program to verify the new Encana standard. Regards, Eric Keyser ######################################################## Alan Bradshaw, Earth Signal -great initiative -let's get SeisX to correct their data type flag (version 4.0 corrects it) -The SEG standard from the UK does not acknowledge the fact that Canada has been using 6 as SUN IEEE Big Endian for more than ten years, this should be acknowledged in the SEG Y rev1 standard. -Keep the standard simple if you want general acceptance ####################################### Gary Billings, Talisman Wants to use integers and scalers to describe floating point numbers in the header. This is closer to the original 1975 standard and numbers can be more accurately expressed. Talisman is currently redoing their standard. It looks like the SEG Y rev1 standard will not meet their requirements either. ####################################### Foster Jansen, Phillips/Conoco/Gulf/Crestar Canada. The Gulf standard has prevailed. All data that is archived on disk is converted from IEEE floating point to IBM floating point. IBM floating point hasn't been used by computers for years! ###################################### Hello Eric: Ray Lipkewich asked me to look at your proposals for the new SEGY format for Encana. Based on a fairly brief reading, these proposals look quite sensible to me, and most of my comments here relate to minor details (but with potentially large impact). Some suggestions: - binary header, bytes 21,22 for data samples per trace... would it be worth making this mandatory, even though this item is also in trace headers? Some systems use this item while initializing and opening a file. - trace header, bytes 37-40, for offset... would it be worth making this mandatory for pre-stack? even though this is derivable from source and receiver coordinates, there may be situations where there is uncertainty about the format of UTM coordinates in trace headers. Also, I have a few questions: - In several places the code '-3' is used to indicate format; does this mean IEEE floating point? Also, in some places codes such as 'A12' are used; I assume this means ASCII characters? - For bytes 17-20 of the trace header you have "2d_shot_sequence_number". I'm not sure what this terminology means, but this location has usually been used for surface station above cdp for 2d stack data, and s.p. ID of the energy source for pre-stack. - UTMX and UTMY are indicated for bytes 81 and 85 of the trace headers; are these intended to be bin centre locations? I look forward to any clarifications you might have on these points, and I'll try to keep an eye open for future revisions. Thanks, Dave Morgan (Geo-X Systems) ############################################# Eric, I like the work you have done on this, Eric. A couple of ideas. Based on your model, I think it would be good idea to incorporate the rotational values as used in Seis-x for 3D stack volumes. I also think it would be a good idea to have some standard for VSP data. ..Steve steve Rogers (srogers@vector-archives.com) ###################################################### Eric, Your mail was forwarded to me by Mike Clement and I have collected a few initial comments/questions about the proposed SEGY standard. We are still looking at some of the items in the high byte numbers that come from the old AEC standard and may have some comments on them soon. -Can you indicate which items are required only for pre-stack data? -Do you want to specify the endian of the IEEE floating point numbers that are written? SEGY Rev1 uses big endian for IEEE just as SEGY Rev0 did for IBM floating point. This is native format for Sun's, IBM, HP etc but it is a byte swap for PC's. The other alternative is that we write native and your applications byte swap when appropriate. In the 400 byte file header: -Do you want byte 27-28 to be the CMP fold or the ensemble fold? In other words, shot fold if I write shots. -Bytes 301 to 306 that are used for line_name take on a mandatory use in SEGY Rev1. If they are left 0 they indicate that this is a SEGY Rev0 file otherwise they have meaning to a segy input that may expect Rev1 data. In the 240 byte trace header: -In byte 71 the coordinates can be specified as metres or decimetres. If the coordinates are stored as decimetres this is not consistent with storing the UTM coordinates in IEEE format. A typical northing in Canada is, say, 5512345 m or 55123450 dm. If this is stored as IEEE the result will be 55123448 dm. The following table shows what some typical northings in decimetres become when converted to real numbers. integer 55123450 real 55123448.000000 integer 55123451 real 55123452.000000 integer 55123452 real 55123452.000000 integer 55123453 real 55123452.000000 integer 55123454 real 55123456.000000 integer 55123455 real 55123456.000000 integer 55123456 real 55123456.000000 integer 55123457 real 55123456.000000 integer 55123458 real 55123456.000000 -The description of byte 105 is confusing. This may not matter as it is not often used. That is it for now Eric, I hope this help. Let me know if you have any questions. Regards, Jeff Jeff Deere Manager Geophysical Technology Veritas GeoServices Ltd. Phone: (403) 205-6248 2200, 715 5th Avenue S.W. Fax: (403) 205-6400 Calgary, AB, T2P 5A2 Email: jeff_deere@veritasdgc.com ###################################################### The only comments I have are: 1. File name length I'm not sure what the maximum file name length is for all the various operating systems. As we've seen before with Microsoft (8.3 filenaming convention for DOS), some systems have different character limits for total file name length. It might be worth investigating OS filenaming conventions, but might not be applicable to Encana. 2. SeisXed 3D files should not be "attached" without a corresponding 3D index file (causes crashes and other problems in some modules). SeisX computes X,Y values based on the corner points supplied during dataloading and has this information in the header, but in the case where this info doesn't exist, SeisX goes to the index file. Perhaps we should change our 3D segy format to remove the index file? That's my 2cents. Everything is looking great. -Ke Lovan (Paradigm) ###################################################### Eric, I have taken your proposal and tried to mane the minimum number of modifications, in doing so I: 1. used all the unused locations 2. re worded a few for clarity/simplicity 3. removed duplicates 4. Moved only one item (207 to 61) 5. Incorporated requirements for marine data 6. And honoured proposals put forward by the CSEG Segy standards (June 94 Recorder) All of these changes are in blue below. Ann O'Byrne (Encana) -attachments ###################################################### I've given this a good general read and it looks to be logical and comprehensive. Eric, you've done a good job morphing the two legacy standards. I'm pleased that we can move forward on this, and I think it is important to get the processing contractors on board as soon as possible. You may wish to run a draft version by one or two of the processors for feedback - Al Bradshaw at Earth Signal comes to mind. Andy Williamson (Encana) ######################################################