Ground Penetrating RADAR (GPR) survey processing

[European GNU Radio Days]

I have been watching OpendTect for a while but never managed to use it for processing GPR data ... until now. I *think* I figured out a decent flowchart but would like some opinion and most significantly am confused with the scale between trace location and geographical position. Rather than a very long post on this list I setup a short web page

summarizing my processing procedure at http://jmfriedt.free.fr/opendtect/opendtect.html

Not being familiar with seismology and the apparently nice regular tracks used, I struggled at first with In-line and Cross-line and am still struggling with the very first step of defining the Survey geometry. After spending a significant amount of time trying to fill the headers of Seismic Unix logs to comply with the requirements of OpendTect, I gave up and am now importing 2D ASCII files holding the data prefixed with X and Y position.

I any one can have a quick look at the web page, my confusion comes from filling the initial Survey setting of In-line range from 0 to 1 with step 1, Crossline range from 0 to 1 with step and then Coordinate Settings: First In-line/Cross line: (1,0) maps to (X,Y)=1,0 ; Another position: (0,0) maps to (X,Y)=0,0 ; Position not on above line: (0,1) maps to (0,1). Whatever scaling I use between inline/crossline and X-Y, I always end up with a geometry location of my B-scans at the same location on the grid. Ideally of course I'd lilke my data to be at the "right" geographical location since at the moment I had to remove the bottom left corner coordinates to have something between 0 and 1 in the in-line/cross range framework despite by X and Y being between 0 and 500 m.

Any help would be welcome as I believe with this last information I could complete a full opensource GPR acquisition (https://sourceforge.net/projects/proexgprcontrol) and processing chain.

Thank you, Jean-Michel

[Paul de Groot]

Hello Jean-Michel,

OpendTect makes a distinction between 2D data (profiles) and 3D data (regularly sampled data), see Survey Setup in the training manual. An OpendTect project can be set up for 2D data, for 3D data or for both. All projects must be set up with X,Y coordinates linked to an Inline, Crossline grid. When the project is set up for 3D data, the Inline, Crossline grid is the grid defined by the 3D seismic. OpendTect uses this definition to find seismic inlines and crosslines to display, process and interpret. The 3D seismic data must fall completely inside the Inline, Crossline survey box defined in the survey setup window.

If the project is set up for 2D data only, the Inline, Crossline definition is not that important. 2D lines can stick out of the defined Inline, Crossline survey box. OpendTect finds the information to display, process and interpret from the X,Y information that MUST be present in each trace of the 2D data. The Inline, Crossline definition is only used for gridding operations.

Coming to your problem. I don't have experience with GPR data but OpendTect does support import of DTZ format data, which is the standard for GPR data. DTZ format must have X,Y coordinates in the headers. You can find the import option under the Survey -> Import -> Seismic Data -> GPR: DTZ format ... menu.

OpendTect can handle crooked 2D lines but I'm not sure what it will do with 2D profiles that fold back on itself. If that creates a problem, you may want to split your profile into 2 or 3 sections: the zig-zag part and the parts that are more or less straight.

I hope this helps.

Best regards,

Paul.

--

Paul de Groot

Geoscience Manager

-----------------------------------------------------------------------------------------------------------------------   dGB Earth Sciences
Phone: +31 53 4315155 E-mail: paul.d...@dgbes.com Internet: dgbes.com

----------------------------------------------------------------------------------------------------------------------- 

--
You received this message because you are subscribed to the Google Groups "OpendTect Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to users+un...@opendtect.org.
To view this discussion on the web visit https://groups.google.com/a/opendtect.org/d/msgid/users/9c65a1fe-3df1-4c76-9899-abaa57f82197n%40opendtect.org.

[European GNU Radio Days]

Thank you for the support in this answer and the emails I got in private. Actually after a night of thinking and starting from a fresh project, it all ended up adding together, indeed using 2D datasets and not focusing on 3D.

For the record and potential other users, I have documented my endeavour at http://jmfriedt.free.fr/opendtect/opendtect.html and while I am quite pleased with the result thanks to this excellent software, I am always open to comments to improve the processing flowchart.

I will now try to see how to compensate for topography for more complex geographical settings such as mountain glaciers, but that is another story.

Thank you, Jean-Michel

[European GNU Radio Days]

For the record, following advice received off list that matches my past experience with Seismic Unix of filling initial measurements of each trace with as many dummy data (NaN will appear as transparent when displayed by OpendTect) to move the origin at the equivalent altitude since none of the SEG-Y fields I tried seemed to move the origin of the displayed traces, I ended up with the result I expected as described at http://jmfriedt.free.fr/opendtect/opendtect_segy.html

Thank you for the support and the excellent software I really enjoyed learning,

Jean-Michel