Seg2 reading/writing issue

Hi everyone,
and best wishes for 2022 to all obspy users & dev team!

I am posting here because I face an issue when reading .seg2 files coming from Geometrics instruments (namely Geometrics Smartseis, pretty old instruments but still in service!).
Those files are saved with .dat extension, but they seem actually to be .seg2. They appear to be quite akward, as described here: Geopsy: Supported file formats - GeopsyWiki

I want to read them using obspy (v1.2.2), correct the faulty fields/trace format and then save them again into files for refraction processing using “Sardine” software (Demanet, 2000). Indeed, direct import with either “Sardine” or “geopsy” software fails.

This issue might be related to #2634 #2022 and #2385 issues on github.

Here attached are my codes: (41.2 KB)

When I import the .dat files into obspy using, I get a stream with many missing fields.
Thus, I write them using the attached script which reads the st.stats[‘seg2’] dictionnary.

Missing/incorrect fields are namely:
o trace distance (x coordinate)
o trace data encoding (I have to convert it into np.float32)

Unfortunately, I can’t save this trace back into .SEG2 files (this is not possible with obspy). Thus, I choose the “.SU” format (other formats lead to weird/not readable files with Sardine software).

This leads to another issue: many fields are not transfered from the .SEG2 file into the .SU file.
I have to re-write them manually, notably:
o delay before recording
o trace id
o source coordinate x and y
o groupe coordinate x and y
o some other fields, not important
I managed to do all that, but 1 issue remains:

The issue here is that source and group coordinate MUST be integers in .SU files, whereas my field data scheme contains decimal numbers (e.g. shot position at 100.5m).

This issue prevents me from using the Sardine picking software right after the obspy conversion.

If someone may have a clue for helping me, that would be very nice! I think this issue could be tackled at different steps of the processing, but I am struggling to make it work.

(Currently, I write ‘false’ x coordinates in .SU files by multiplying their coordinates by 10 to remove decimal numbers. Then I open manually each converted .SU file with Sardine, saving them back into SEG2. Finally, I divide the x coordinates by 10 using Sardine and re-save it into SEG2. This is quite heavy, especially with surveys with many acquisitions).