teekrot.blogg.se - Segy detective

#SEGY DETECTIVE SOFTWARE#

Give it the inline and xline bytes, and anything else you need.

If I have a geometry already I'm just looking for inline, xline, and data check No (you almost always need to change byte locs), and Next

Look at the header and trace headers, and figure out where the data are.

Select the file, ask for at least twice the number of traces that you have in an inline (or just put 1000), and say 'format' from header click Next.

Here are the specifics of the workflow in OpendTect: But there's nothing like that in your file. Often (in a North American UTM zone) this is a 6-digit x and a 7-digit y location, almost always in consecutive byte locations. Finding a coordinate byte is often just a matter of looking for something that looks like coordinates. These increase like so, for a 3 × 3 3D survey: In a 3D, you have to find the line and CDP numbers (or inline and crossline, if you prefer). Basically they can be anywhere.įiguring out the location of the trace numbers isn't always a picnic either. Bytes 181 and above are undefined in the SEG standard, so sometimes people put coordinates there. If there are coordinates in a SEG-Y file, they're supposed to be in bytes 73 and 77.

#SEGY DETECTIVE SOFTWARE#

All seismic data loading software have a trace header viewer.

Petrel's loader will certainly let you do this too, I just don't know how. Ask for 1000 traces, to get a good look at the headers. To see the byte headers, you can use OpendTect > Survey > Import > Seismic > SEGY, and select your file. The headers map the meaning to the location, e.g. Each word has its own address, or 'location' (a number), and a meaning. The data are stored on the file in 4-byte 'words'. The traces also have two bits: a header and the data. Your EBCDIC header is almost useless, as they often are. SEG-Y files have two components: the EBCDIC header and the traces. I even saw one upside-down (in the z dimension) once, but that's another story. I can't count the number of back-to-front surveys I've seen. Of vital importance is some independent corroboration - a map, ideally - of the geometryand the shape and orientation of the survey. This doesn't help you much without navigation, however. In your file, it looks like you can use byte 21. So all you really want to get from the SEG-Y are the trace numbers, which are usually in a low byte number. Load the actual TRACES, which are the meat of the SEG-Y file (but are not human-readable). The cross-reference is the trace number (or CDP number, or line and xline numbers, or whatever you have). Load the traces into their homes, often one line at a time for 2D.Better to have a navigation file, or annotated map, or something separate. Sometimes this info is in the SEG-Y file, but often this is an unreliable source of nav data. It's variously called 'navigation', 'survey', or some other synonym. In other words, the geometry tells you where the traces go. Create a GEOMETRY, which is a description of where the line goes on the earth, in surface coordinates, and where the starting trace is, how many traces there are, and what the trace spacing is. For 3D it may be in the processing report or in the ASCII or EBCDIC header of the SEG-Y file. Note that for 2D data the geometry is usually in a separate nav file. Define the survey geometry, at every trace for a 2D, or just with corner-points for a 3D.So my standard procedure for loading data is: You just don't know where it's been, or what has happened to it along the way - what's the datum? What are the units? And so on. Because this can be such a hard problem to troubleshoot, I never trust location data in a SEG-Y file.

In a nutshell, the specific problem both these people experienced was missing or bad trace location data. After some epic emails, I realized I need to write a post about it - next time I can just send a URL! In both cases, the frustration stemmed from the same problem. Twice in the last year, I've heard from people experiencing lots of frustration with loading SEG Y seismic data.