Loading the survey: where are the inline and crossline numbers?
Learning objectives
- Read a SEG-Y textual and binary header and say what the file claims about itself
- Find the trace-header byte positions that carry the inline and crossline numbers
- Recognise the three ways a wrong byte choice produces a survey that looks like data
- Explain why a transposed survey generates no warning from any software
Every interpretation project in the world begins the same way. A file arrives from the processor, and before you can look at a single reflector you have to answer a question the file will not answer for you: where, in each 240-byte trace header, are the inline and crossline numbers?
The SEG-Y standard has an opinion about this and the industry has largely ignored it. Bytes 189 and 193 are common. So are 181 and 185. So are 9 and 21. The processor chose, and unless somebody wrote it down, you are going to have to work it out.
Why this matters more than it sounds like it should
The failure mode is not that the file refuses to load. It loads. It always loads. What changes is what you get.
Read a trace counter as the inline number and you get one inline per trace: a survey 16,500 lines wide and one line deep. That one announces itself, because the geometry cannot close.
Read the CDP X and Y coordinates instead of the line numbers and you get a survey of exactly the right shape, numbered in metres. Every section displays correctly. Nothing matches the well locations, the horizon names, or anything else the client ever sent you.
Swap the two and you get the worst case. The file loads cleanly. The geometry closes. Every inline you display is actually a crossline. Nothing in the file can detect this, no software will warn you about it, and you will find out when a well comes in 800 metres from where you said it would.
The header is the only thing that can save you
The textual header is 3200 bytes of EBCDIC, which is a character encoding IBM designed in 1963 and which survives in this one place because SEG-Y was written in 1975 and nobody has been brave enough to change it. Read it as ASCII and you get mojibake. That is worth seeing once.
Line 7 of this particular header states the byte positions. Many real headers do. Many do not, and for those the scan is all you have: read every four-byte position across a few hundred traces and rank them by how much each behaves like a survey coordinate rather than a counter. That is what commercial packages do when you press "scan headers", and the answer comes back as candidates, because the file genuinely does not say.