[GRASS-dev] v.in.ogr: how to force sqlite instead of dbf for output location ? SEG-Y input (Geology/Seismic Data)

[Hamish]

Peter wrote:
> When trying to ingest SEG-Y data (geology/seismics) into a
> new location via v.in.ogr (GDAL 1.9.0) this error is thrown

can I ask what part of it you are trying to load? The actual trace
data (time vs amplitude) or to extract the navigation data for
source, receiver, or CDP?

I'm working with this data all the time and know it pretty well,
for marine date often there's a P1/90 file along with it containing
the nav data & I've written a v.in.p190 script in GRASS addons to
load that. (some assembly may be required)

for just SEG-Y the route I would probably take would be to run it
through MB-System's mbsegylist or some header print program from
Seismic UNIX (both codes are free) to make a shot_number,x,y,..
ascii file and then import it with v.in.ascii.



> since the new location is set by default (?) to dbf:
...
> The initial location from which v.in.ogr was invoked was already
> switched to a sqlite-backend. How can this issue be overcome ?

see the db.connect man page for examples. switch it then switch it
back afterwards.

> -> I'm no SEG Y guru, so having v.in.ogr infer the settings for the 
> resulting target location would be required. 

Try mbsegyinfo from MB-System to get the bounds.


http://www.ldeo.columbia.edu/res/pi/MB-System/
http://www.cwp.mines.edu/cwpcodes/

there's also a freeware viewer called SeiSee which can run under
Wine for exploring the headers (test endianness, IBM vs IEEE floating
point (not always obvious), ASCII vs. EBCDIC headers vs. both!...)
http://www.dmng.ru/seisview/

note SEG-Y positions are stored as integers, so if weird try UTM-as-
decimeters and lat/lon converted into milli-arc-seconds.
( {long,lat} = SOURCE_{X,Y}/(1000*60^2) ) 



Hamish