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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |