Re: [GRASS-dev] v.in.ogr: how to force sqlite instead of dbf for output location ? SEG-Y input (Geology/Seismic Data)
Peter wrote: > I'm evaluating the SEG-Y formate to exchange data between software packages > from the exploration industry like Petrel and Gocad and GRASS. So far only > demo > data sets are used. I will inquire wether P1/90 is also available. links: http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6#v.in.p190 "For working with SEG-Y data, see also the v.in.mbsys_fnv addon." http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6#v.in.mbsys_fnv the workflow for v.in.mbsys_fnv is to use MB-System to create ancillary support files from the SEG-Y trace headers (the navigation data ends up in a .fnv file), then use the addon module to import those as points or track lines. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.in.ogr: how to force sqlite instead of dbf for output location ? SEG-Y input (Geology/Seismic Data)
Hamish, > > 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? Thanks for your advice! I'm evaluating the SEG-Y formate to exchange data between software packages from the exploration industry like Petrel and Gocad and GRASS. So far only demo data sets are used. I will inquire wether P1/90 is also available. Peter ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.in.ogr: how to force sqlite instead of dbf for output location ? SEG-Y input (Geology/Seismic Data)
Peter Löwe 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 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 ? You can use from any location g.proj georef=demo20071121142735_CH1_35P.seg location=segy_sqlite This will create a new location with the projection information of the given dataset, but will not import the dataset. Then you would need to switch to a mapset in the new location, set default db backend to sqlite with db.connect and import the dataset with v.in.ogr. Or easier, use GRASS 7. HTH, Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.in.ogr: how to force sqlite instead of dbf for output location ? SEG-Y input (Geology/Seismic Data)
On 25/09/13 21:25, "Peter Löwe" wrote: The initial location from which v.in.ogr was invoked was already switched to a sqlite-backend. How can this issue be overcome ? Just a note: you cannot switch a location to a specific backend. This setting is per mapset. In grass6, each new mapset created has dbf as its database backend. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.in.ogr: how to force sqlite instead of dbf for output location ? SEG-Y input (Geology/Seismic Data)
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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] v.in.ogr: how to force sqlite instead of dbf for output location ? SEG-Y input (Geology/Seismic Data)
Hi list, I'm using GRASS6.4.2 on a Suse-based HPC Cluster. 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 since the new location is set by default (?) to dbf: GRASS 6.4.2 (startup_sqlite):~/geodata/petrel/SEG_Y_Demo > v.in.ogr dsn=demo20071121142735_CH1_35P.seg output=seg_y_test location=segy_sqlite Layer: demo20071121142735_CH1_35P WARNING: Default driver / database set to: driver: dbf database: $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ WARNING: Column type not supported (SAMPLE_ARRAY) WARNING: DBMI-DBF driver: column name 'TRACE_NUMBER_WITHIN_LINE' truncated to 'TRACE_NUMB' WARNING: DBMI-DBF driver: column name 'TRACE_NUMBER_WITHIN_FILE' truncated to 'TRACE_NUMB' DBMI-DBF driver error: Column 'TRACE_NUMB' already exists (duplicate name) Cannot create table. Error in db_execute_immediate() ERROR: Unable to create table: 'create table seg_y_test_1 (cat integer, TRACE_NUMBER_WITHIN_LINE integer, TRACE_NUMBER_WITHIN_FILE integer, ORIGINAL_FIELD_RECORD_NUMBER integer, TRACE_NUMBER_WITHIN_ORIGINAL_FIELD_RECORD integer, TRACE_IDENTIFICATION_CODE integer, ENSEMBLE_NUMBER integer, TRACE_NUMBER_WITHIN_ENSEMBLE integer, NUMBER_VERTICAL_SUMMED_TRACES integer, NUMBER_HORIZONTAL_STACKED_TRACES integer, DATA_USE integer, DISTANCE_SOURCE_GROUP integer, RECEIVER_GROUP_ELEVATION integer, SURFACE_ELEVATION_AT_SOURCE integer, SOURCE_DEPTH_BELOW_SURFACE integer, DATUM_ELEVATION_AT_RECEIVER_GROUP integer, DATUM_ELEVATION_AT_SOURCE integer, WATER_DEPTH_AT_SOURCE integer, WATER_DEPTH_AT_GROUP integer, VERTICAL_SCALAR integer, HORIZONTAL_SCALAR integer, SOURCE_X integer, SOURCE_Y integer, GROUP_X integer, GROUP_Y integer, COORDINATE_UNITS integer, WEATHERING_VELOCITY integer, SUB_WEATHERING_VELOCITY integer, UPHOLE_TIME_AT_SOURCE integer, UPHOLE_TIME_AT_GROUP integer, SOURCE_STATIC_CORRECTION integer, GROUP_STATIC_CORRECTION integer, TOTAL_STATIC_CORRECTION integer, LAG_TIME_A integer, LAG_TIME_B integer, DELAY_RECORDING_TIME integer, MUTE_TIME_START integer, MUTE_TIME_END integer, SAMPLES integer, SAMPLE_INTERVAL integer, GAIN_TYPE integer, INSTRUMENT_GAIN_CONSTANT integer, INSTRUMENT_INITIAL_GAIN integer, CORRELATED integer, SWEEP_FREQUENCY_AT_START integer, SWEEP_FREQUENCY_AT_END integer, SWEEP_LENGTH integer, SWEEP_TYPE integer, SWEEP_TRACE_TAPER_LENGTH_AT_START integer, SWEEP_TRACE_TAPER_LENGTH_AT_END integer, TAPER_TYPE integer, ALIAS_FILTER_FREQUENCY integer, ALIAS_FILTER_SLOPE integer, NOTCH_FILTER_FREQUENCY integer, NOTCH_FILTER_SLOPE integer, LOW_CUT_FREQUENCY integer, HIGH_CUT_FREQUENCY integer, LOW_CUT_SLOPE integer, HIGH_CUT_SLOPE integer, YEAR integer, DAY_OF_YEAR integer, HOUR integer, MINUTE integer, SECOND integer, TIME_BASIC_CODE integer, TRACE_WEIGHTING_FACTOR integer, GEOPHONE_GROUP_NUMBER_OF_ROLL_SWITH integer, GEOPHONE_GROUP_NUMBER_OF_TRACE_NUMBER_ONE integer, GEOPHONE_GROUP_NUMBER_OF_LAST_TRACE integer, GAP_SIZE integer, OVER_TRAVEL integer)' The initial location from which v.in.ogr was invoked was already switched to a sqlite-backend. How can this issue be overcome ? -> I'm no SEG Y guru, so having v.in.ogr infer the settings for the resulting target location would be required. Cheers, Peter ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
