Loading the survey: where are the inline and crossline numbers?

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?

This part of the course is a single piece of software, and it opens below. The workstation carries one project through all seven sections: the faults you pick in the next section are the faults on your final map, and the tie you accept in 11.5 moves your depth conversion. Start in the Data Room: download the transmittal, the way it would actually arrive, then drag the SEG-Y back in and load it.

Why the load is a decision, not a formality

The SEG-Y standard has an opinion about where line numbers live 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 work it out.

The failure mode is not that the file refuses to load. It loads. It always loads. Read a trace counter as the inline number and you get a survey sixteen thousand lines wide and one line deep; that one announces itself, because the geometry cannot close. Read the CDP X and Y coordinates at 181 and 185 and you get a survey of exactly the right shape, numbered in metres; every section displays correctly and nothing ever matches the well locations. Swap inline and crossline and you get the worst case: the file loads cleanly, the geometry closes, and every line you display is at right angles to the one you asked for. Nothing in the file can detect that. The only defences are the header, which states the positions, and a known coordinate such as a well.

The textual header is 3200 bytes of EBCDIC, a character encoding IBM designed in 1963 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. The workstation decodes it for you; real packages do too, but only after somebody has been burned once. Line 7 of this particular header states the byte positions, and many real headers do. For the ones that do not, press SCAN: the workstation reads every four-byte position across a few hundred trace headers and ranks them by how much each behaves like a survey coordinate rather than a counter. That is what the commercial packages do, and the answer comes back as candidates because the file genuinely does not say.

One practical note: the workstation keeps what you import in the browser's own storage, so the 24 MB survey and your interpretation are still here when you come back tomorrow. Nothing leaves your machine.

The Data Room also carries REAL data: an extract of the F3 Netherlands survey from the Dutch North Sea, courtesy of dGB Earth Sciences and the Open Seismic Repository under CC BY-SA 4.0. Load it after the Ogbon file and notice that its line numbers live at different trace-header bytes, which its own header documents; two files, two conventions, one habit worth keeping. No public well transmittal accompanies the extract, so picking, gridding, amplitude, statistics and the 3D scene run on real data while the tie and depth stages stay with the Ogbon package. Your two interpretations are kept separately; switching surveys never discards either.